В двух словах, ZooKeeper помогает вам создавать распределенные приложения.
Как это работает
Вы можете описать ZooKeeper как реплицированную службу синхронизации с возможной согласованностью. Это надежно, поскольку постоянные данные распределяются между несколькими узлами (этот набор узлов называется «ансамблем»), и один клиент подключается к любому из них (т. Е. К определенному «серверу»), мигрируя при сбое одного узла; до тех пор, пока работает строгое большинство узлов, ансамбль узлов ZooKeeper жив. В частности, главный узел динамически выбирается путем консенсуса в ансамбле; в случае сбоя главного узла роль мастера переносится на другой узел.
Как обрабатываются записи
Мастер является полномочным для записи: таким образом, запись может быть гарантированно сохранена в порядке, т.е. записи являются линейными . Каждый раз, когда клиент записывает в ансамбль, большинство узлов сохраняет информацию: эти узлы включают в себя сервер для клиента и, очевидно, мастер. Это означает, что при каждой записи сервер обновляется с мастером. Это также означает, однако, что вы не можете иметь одновременные записи.
Гарантия линейной записи является причиной того факта, что ZooKeeper неэффективен для рабочих нагрузок с доминированием записи. В частности, он не должен использоваться для обмена большими данными, такими как медиа. Если ваше общение связано с общими данными, ZooKeeper поможет вам. Когда данные могут быть записаны одновременно, ZooKeeper фактически мешает, потому что он налагает строгий порядок операций, даже если это не является строго необходимым с точки зрения авторов. Его идеальное использование для координации, когда сообщения обмениваются между клиентами.
Как читаются обрабатываются
Вот где ZooKeeper превосходит: чтения происходят одновременно, поскольку они обслуживаются конкретным сервером, к которому подключается клиент. Однако это также является причиной возможной согласованности: «представление» клиента может быть устаревшим, поскольку мастер обновляет соответствующий сервер с ограниченной, но неопределенной задержкой.
В деталях
Реплицированная база данных ZooKeeper содержит дерево znodes , которые представляют собой сущности, приблизительно представляющие узлы файловой системы (представьте их как каталоги). Каждый znode может быть обогащен байтовым массивом, в котором хранятся данные. Кроме того, каждый znode может иметь под собой другие znode, практически образуя внутреннюю систему каталогов.
Последовательные узлы
Интересно, что имя znode может быть последовательным , что означает, что имя, которое клиент предоставляет при создании znode, является только префиксом: полное имя также задается порядковым номером, выбранным ансамблем. Это полезно, например, для целей синхронизации: если несколько клиентов хотят получить блокировку ресурса, каждый из них может одновременно создать последовательный znode в местоположении: тот, кто получает наименьшее число, имеет право на блокировку.
Эфемерные Зноды
Кроме того, znode может быть эфемерным : это означает, что он уничтожается, как только клиент, который его создал, отключается. Это в основном полезно для того, чтобы знать, когда клиент терпит неудачу, что может быть актуально, когда у самого клиента есть обязанности, которые должен взять на себя новый клиент. Принимая пример блокировки, как только клиент, имеющий блокировку, отключается, другие клиенты могут проверить, имеют ли они право на блокировку.
Часы
Пример, связанный с отключением клиента, может быть проблематичным, если нам нужно периодически опрашивать состояние узлов. К счастью, ZooKeeper предлагает систему событий, где часы могут быть установлены на znode. Эти часы могут быть настроены на запуск события, если znode специально изменен или удален, или под ним созданы новые дочерние элементы. Это явно полезно в сочетании с последовательными и эфемерными вариантами для znodes.
Где и как его использовать
Каноническим примером использования Zookeeper является вычисление с распределенной памятью, когда некоторые данные распределяются между клиентскими узлами и должны быть доступны / обновлены очень осторожно, чтобы учесть синхронизацию.
ZooKeeper предлагает библиотеку для создания ваших примитивов синхронизации, а возможность запуска распределенного сервера позволяет избежать проблемы единой точки отказа, которая возникает при использовании централизованного (подобного брокеру) хранилища сообщений.
ZooKeeper - это функциональный индикатор, означающий, что такие механизмы, как выбор лидера, блокировки, барьеры и т. Д., Еще не представлены, но могут быть записаны над примитивами ZooKeeper. Если C / Java API слишком громоздок для ваших целей, вам следует полагаться на библиотеки, созданные на ZooKeeper, такие как cages и, особенно, куратор .
Где читать дальше
Помимо официальной документации, что довольно неплохо, я предлагаю прочитать главу 14 Hadoop: «Полное руководство», которая содержит ~ 35 страниц, объясняющих, в основном, что делает ZooKeeper, а затем пример службы конфигурации.