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