Использование Zookeeper в реальном мире [закрыто]

Я недавно смотрел Zookeeper и задавался вопросом, использует ли кто-нибудь его в настоящее время и что они конкретно использовали для хранения.

Чаще всего используется информация о конфигурации, но какие данные и сколько данных вы храните?

Реализация Apache CXF для DOSGi использует zookeeper в качестве репозитория регистрации служб. Отдельные контейнеры имеют пакет распределенного программного обеспечения (dsw), который отслеживает все события службы и при изменении статуса службы, имеющую свойство, указывающее на распространение. Dsw обращается к пакету обнаружения, который в случае эталонной реализации использует zookeeper для хранения службы в виде эфемерных узлов. Другие экземпляры будут искать изменения в структуре узлов и регистрировать прокси в своих локальных системах. Конечным результатом является то, что вы можете писать код на простой OSGi и получить прозрачное распределение.

Проекты свободного программного обеспечения на базе ZooKeeper:

• AdroitLogic UltraESB
• Akka
• Коммуникационная среда Eclipse
• Eclipse Gyrex
• GoldenOrb
• амулет
• Катта
• KeptCollections
• Mesos
• Neo4j
• Norbert
• Таленд ESB
• redis_failover

Проекты Apache на базе ZooKeeper:

• Apache Accumulo
• Apache BookKeeper
• Apache CXF DOSGi
• Apache Flume
• Apache Hadoop MapReduce
• Apache HBase
• Апач Хедвиг
• Апач Кафка
• Apache S4
• Apache Solr

Источник: https://cwiki.apache.org/confluence/display/ZOOKEEPER/PoweredBy

HBase использует Zookeeper для координации действий, за которые отвечал его «головной узел» до текущей версии. Переход к использованию Zookeeper означает, что центральное управление больше не является единственной точкой отказа.

Zookeeper очень универсален; вот пример его использования для построения распределенной параллельной очереди:

http://blog.cloudera.com/blog/2009/05/building-a-distributed-concurrent-queue-with-apache-zookeeper/

Конечно, вы также можете использовать его для создания блокировок ресурсов и т. Д. В распределенной системе.

Старый вопрос, но поскольку эта страница появляется первой при поиске в Google вариантов использования zookeeper, я подумал, что было бы лучше предоставить обновленный список

1. википедия
2. zookeeper вики
3. реальные пользователи

Норберт - хороший пример масштабируемой производственной системы. В целом, он объединяет Netty, Protocol Buffers и Zookeeper в легкую структуру для запуска кластерных служб. Буферы протокола используются для определения API вашей службы, Netty реализует абстракции транспортного уровня, а Zookeeper по сути является отказоустойчивой службой обнаружения.

Каждый раз при запуске экземпляра службы Норберт регистрирует его как доступный экземпляр определенного типа службы. С точки зрения реализации он создает два дерева Zookeeper:

• "/ ServiceName / members", в котором перечислены все известные экземпляры службы.
• "/ ServiceName / available" - список доступных на данный момент экземпляров службы.

Самым важным свойством каждого узла является URL-адрес, используемый для подключения к соответствующему экземпляру службы. Он обеспечивает балансировку нагрузки на стороне клиента - клиент Norbert находит список URL-адресов для данного имени службы и пытается подключиться к одному из них в некотором порядке (например, циклический или случайный).

О ZooKeeper в Elastic Cloud есть хорошая статья ZooKeeper - The King of Coordination .

В Found, например, мы широко используем ZooKeeper для обнаружения, распределения ресурсов, выбора лидера и уведомлений с высоким приоритетом. В этой статье мы познакомим вас с этим королем координации и внимательно рассмотрим, как мы используем ZooKeeper в Found

Solr также работает над интеграцией ZooKeeper . Здесь вы можете увидеть, что они используются для динамической конфигурации, сегментирования, исключения SPOF (выбор главного / подчиненного устройства), перебалансировки и т. Д.

• Storm используется рядом компаний (Twitter и Groupon - две из наиболее известных) и полагается на Zookeeper.
• Kafka используется Linkedin и полагается на Zookeeper.

Storm использует Zookeeper для хранения всего состояния, чтобы он мог восстанавливаться после сбоя в любой из своих (распределенных) компонентных служб.

Это позволяет компонентным службам не иметь состояния и просто загружать или синхронизировать с серверами Zookeeper, когда требуются данные конфигурации. Если вам когда-либо приходилось восстанавливать рабочий сервер, вы знаете, какая это может быть головная боль!

Потребители очереди Kafka могут использовать Zookeeper для хранения информации (максимальная отметка) о том, что было израсходовано из очереди.

В моем случае мы храним файлы конфигурации в ансамбле zookeeper для использования в кластере. Мы используем схему лидер -> последователь. Итак, когда один смотритель зоопарка выходит из строя, мы переключаемся на другого (режим репликации)

Zookeeper использовался не только для настройки. Вот официальный список реализации распределенных примитивов с помощью zookeeper.

https://zookeeper.apache.org/doc/current/recipes.html

Neo4j использует Zookeeper на своем корпоративном сервере высокой доступности! http://docs.neo4j.org/chunked/milestone/ha.html

datomic использует apache zookeeper для управления хранилищем данных на основе riak.

Поскольку в настоящее время Riak поддерживает только конечную согласованность, система Datomic, работающая на Riak, также использует Apache ZooKeeper, высокодоступную службу координации. Datomic использует ZooKeeper для координации аварийного переключения транзакторов и для нескольких ключей для каждой базы данных, которые необходимо обновить с помощью CAS. источник: http://blog.datomic.com/2012/11/riak-and-couchbase-support.html

Вот некоторые подробности о том, как HBase использует ZooKeeper , включая информацию о том, как они собираются использовать его в будущем. Обычно они используют его для устранения SPOF на серверах региона через выборы лидера, реализованные с помощью ZooKeeper.