Объясняя Apache ZooKeeper

Я пытаюсь понять ZooKeeper, как он работает и что он делает. Есть ли приложение, которое можно сравнить с ZooKeeper?

Если вы знаете, то как бы вы описали ZooKeeper для неспециалистов?

Я пробовал Apache Wiki, Zookeeper SourceForge ... но я до сих пор не могу с этим справиться.

Я только что прочитал http://zookeeper.sourceforge.net/index.sf.shtml , так что, разве нет таких сервисов? Это так просто, как просто репликация серверной службы?

В двух словах, 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, а затем пример службы конфигурации.

Zookeeper - один из лучших серверов и сервисов с открытым исходным кодом, который помогает надежно координировать распределенные процессы. Zookeeper - это система CP (см. Теорему CAP), которая обеспечивает согласованность и допуск разделения. Репликация состояния Zookeeper на всех узлах делает его в конечном итоге согласованным распределенным сервисом.

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

Zookeeper также предоставляет API, который очень прост в использовании. Этот пост, примеры Zookeeper Java API , содержит несколько примеров, если вы ищете примеры.

Так, где мы используем это? Если вашей распределенной службе требуется централизованное, надежное и согласованное управление конфигурацией, блокировками, очередями и т. Д., Вы найдете Zookeeper надежным выбором.

Я в целом понимаю ZooKeeper, но у меня были проблемы с терминами «кворум» и «разделенный мозг», поэтому, возможно, я смогу поделиться с вами своими выводами (я считаю себя также неспециалистом).

Допустим, у нас есть кластер ZooKeeper из 5 серверов. Один из серверов станет лидером, а другие станут последователями.

• Эти 5 серверов образуют кворум. Кворум просто означает, что «эти серверы могут голосовать за то, кто должен быть лидером».

• Таким образом, голосование основано на большинстве. Большинство означает просто «больше половины», поэтому более половины серверов должны согласиться, чтобы конкретный сервер стал лидером.

• Так что может случиться такая плохая вещь, которая называется «раздвоенный мозг». Насколько я понимаю, разделение мозгов - это просто: кластер из 5 серверов делится на две части, или, назовем это «серверными командами», где может быть одна часть из двух, а другая из трех серверов. Это действительно плохая ситуация, так как если обе «серверные команды» должны выполнить определенный заказ, как бы вы решили, какая команда должна быть предпочтительной? Они могли получить различную информацию от клиентов. Поэтому очень важно знать, какая «серверная команда» по-прежнему актуальна, а какую можно / нужно игнорировать.

• Большинство также является причиной, по которой вы должны использовать нечетное количество серверов. Если у вас есть 4 сервера и разделенный мозг, где 2 сервера разделены, то обе «серверные команды» могут сказать: «Эй, мы хотим решить, кто является лидером!» но как решить, какие 2 сервера выбрать? С 5 серверами все просто: серверная команда с 3 серверами имеет большинство и может выбрать нового лидера.

• Даже если у вас есть только 3 сервера, и один из них выходит из строя, другие 2 по-прежнему составляют большинство и могут согласиться с тем, что один из них станет новым лидером.

Я понимаю, как только вы подумаете об этом и поймете, что это уже не так сложно. Я надеюсь, что это также помогает любому в понимании этих терминов.

Zookeeper - это централизованный сервер с открытым исходным кодом для поддержки и управления информацией о конфигурации, соглашениями об именах и синхронизации для среды распределенного кластера. Zookeeper помогает распределенным системам снизить сложность управления, обеспечивая низкие задержки и высокую доступность. Изначально Zookeeper был подпроектом для Hadoop, но теперь это независимый проект верхнего уровня Apache Software Foundation.

Больше информации

Я бы предложил следующие ресурсы:

1. Документ: https://pdos.csail.mit.edu/6.824/papers/zookeeper.pdf
2. Лекция, предлагаемая MIT 6.824 с 36:00: https://youtu.be/pbmyrNjzdDk?t=2198

Я бы посоветовал посмотреть видео, прочитать газету, а затем снова посмотреть видео. Было бы легче понять, если бы вы знали Raft заранее.