Обзор возможностей библиотеки Apache Curator для Apache Zookeeper

[ivankudryavtsev]

К сожалению, я не знаком детально с etcd. Мне кажется, что etcd — это больше про конфигурацию и discovery, в этом смысле его разумнее сравнивать с consul, а zookeeper, в контексте данной статьи, — про координацию.

Кроме того, согласно статье он только в последних версиях начал поддерживать DLM, что требует проведения бенчмарков, как минимум для того, чтобы объективно выбрать решение. Многие вещи можно и на in-memory grid делать — на том же Hazelcast, Ignite, да хоть на MySQL, но здесь речь про Apache Zookeeper.

Честно говоря, не думаю, что все бросятся переходить на etcd. Причин несколько, одна из существенных — если у вас развернута инфраструктура, в которой уже есть Zookeeper, а таких инфраструктур много, то проще продолжать использовать его, нежели переходить на другую систему.

[ivankudryavtsev]

Все верно, но это не производительность для целей координации, а для конфигурации. Видел этот обзор. Я же говорю, меня Zookeeper для целей конфигурации меньше интересует, чем возможности для координации. Об этом статья и написана.

Еще раз, я не говорю, что Etcd плохой, а Zookeeper хороший.

[AstarothAst]

Я не совсем понял, есть ли у ZooKeeper'а возможность разворачиваться не отдельным сервером, а в embedded виде? Ну, то есть пишу я приложение, и хочу иметь возможность обновляться без остановки оного. Поднимаю два экземпляра, у каждого внутри стартован экземпляр zookeeper'а, эти экземпляры здороваются, и ноды могут друг про друга все узнавать — умерла одна, вторая начала процессить запросы, первая обновилась, сказала «я главная», поменялись местами. Или я хочу странного?

[ivankudryavtsev]

Лучший ответ на ваш вопрос вот здесь — серверы должны знать о друг друге заранее.

То, что Вы хотите, можно реализовать на Hazelcast, к примеру, там есть динамическое присоединение к кластеру.

[IvanPonomarev]

Спасибо за статью. Скажите, а в какую сторону Вы бы смотрели, решая вот такую задачу, подойдёт ли тут ZooKeeper?

В сети на разных серверах есть N совершенно одинаковых исполнителей (сейчас N около 150). Во всякий момент времени есть список задач (коих всегда разное количество, но меньше, чем N). Надо, чтобы исполнители «разобрали на себя» задачи из списка, т. е. каждой из задач соответствовал бы свой исполнитель. Исполнитель не может взять больше одной задачи. Одну задачу потенциально могут взять два исполнителя, но это нежелательно. Исполнители могут как «отваливаться» по той или иной причине, так и приходить новые в пул, и надо чтобы как можно быстрее задачу у «отвалившегося» исполнителя перехватывал другой исполнитель, т. е. ни одной задачи без исполнителя оставлять нельзя.

Вот сейчас на ключах с TTL в Redis-е у меня реализован самодельный алгоритм. Но (на то он и самодельный) по нему случается, что за задачу «хватается» больше одного исполнителя.

Насколько подобная задача стандартна, чем её лучше всего решать?

[grossws]

Как вариант, посмотреть на Apache Kafka, задачи распределяются внутри consumer group, т. е. одно сообщение в рамках одной consumer group получит только один consumer.

[IvanPonomarev]

Неет, очередь в данном случае не годится, потому что наши задачи имеют другую природу: они протяжённы во времени. Мы имеем список задач, этот список со временем меняется, каждая задача в нём висит, скажем, от получаса до двух часов. И нам надо обеспечить, чтобы пока задача в списке, на неё был назначен исполнитель из пула. Если задача из списка удаляется — исполнитель освобождается. Если исполнитель отваливается — надо назначать другого как можно быстрее.

[grossws]

Неправильно вас понял.

Вполне можно реализовать что-то типа выбора мастера, который снимает свою кандидатуру с других задач как только берется за одну. А когда освобождается — вешает кандидатуру на все имеющиеся задачи.

[ivankudryavtsev]

Добрый день. Это можно сделать на Zookeeper вполне. В данном случае, задачи будут последовательными узлами, а исполнители — эфемерными дочерними узлами (к примеру). Назначение на задачу производится с защитой Distributed Shared Lock. Наличие новых задач проверяется подпиской на родительский узел задач и(или) поллингом.

lock
tasts/
   t00000001
          executorX
   t00000002
          executorY

[IvanPonomarev]

Вот да, спасибо! Похоже на то, что надо.

Но непонятно вот что: по какому критерию Zookeeper понимает, что эфемерный узел пора рубить? В доках пишут: «пока существует пользовательская сессия». Так сессия как таковая может существовать вполне себе долго после того, как процедура обработки, её создавшая, вылетела (если не успела закрыть, например). Zookeeper выбивает сессию по таймауту обращений? А если мы долго заняты обработкой и не обращаемся к Zookeeper? Или открытая сессия шлёт какой-то heartbeat? Опять же если мы её не закроем и потеряем, тогда она его будет слать, пока garbage collector не доберётся? Объясните))

[IvanPonomarev]

Наверное вместо эфемерной ноды лучше создать ноду с TTL и «освежать» TTL в цикле обработки? Но я просто не понимаю механику работы эфемерных нод, а это же одна из основных «фишек» Zookeper.

[ivankudryavtsev]

Можно и так, это зависит от природы обработчиков, если, к примеру, они стартуют в Mesos как одноразовые docker-контейнеры, то при крэше сессия завершится и узел удалится.