Наверное, самая понятная статья о концепции ZooKeeper.

Эта статья была добавлена в документ с открытым исходным кодом: JavaGuide (обложка, которая охватывает основные знания, которые необходимо освоить большинству Java-программистов). адрес:GitHub.com/snail Climb/….

предисловие

Я считаю, что каждый должен быть знаком с ZooKeeper. Но вы действительно понимаете, что такое ZooKeeper? Если кто-то/интервьюер попросит вас рассказать ему, что такое ZooKeeper, как далеко вы сможете ответить?

Я сам использовал ZooKeeper в качестве центра регистрации Dubbo, а при построении solr-кластера использовал ZooKeeper в качестве инструмента управления solr-кластером. Несколько дней назад, обобщая опыт проекта, я вдруг задался вопросом, что же такое ZooKeeper? После долгих размышлений об этом у меня в голове всплывает лишь несколько слов: «①Zookeeper можно использовать в качестве реестра. ②Zookeeper является членом экосистемы Hadoop; ③При построении кластера Zookeeper лучше всего использовать количество серверов." Видно, что мое понимание Zookeeper только на поверхности.

так,В этой статье я надеюсь показать вам немного больше о ZooKeeper. Если вы еще не изучили ZooKeeper, то эта статья станет вашей ступенькой на пути к ZooKeeper. Если вы знакомы с ZooKeeper, эта статья вернет вас к некоторым основным понятиям ZooKeeper.

Наконец,В этой статье рассматриваются только некоторые концепции ZooKeeper, а не использование ZooKeeper и построение кластера ZooKeeper.В Интернете есть статьи, в которых рассказывается об использовании ZooKeeper и построении кластера ZooKeeper, вы можете обратиться к ним самостоятельно, если вам это нужно.

1 Что такое ZooKeeper

Происхождение ZooKeeper

Следующий абзац является выдержкой из раздела Главы 4, Раздела 1 «От Паксиса до смотрителя зоопарка». Рекомендуется прочитать следующее:

Zookeeper впервые был создан исследовательской группой Yahoo Research. В то время исследователи обнаружили, что многие крупномасштабные системы в Yahoo в основном должны были полагаться на аналогичную систему для распределенной координации, но эти системы часто имели распределенные одноточечные проблемы. так,Разработчики Yahoo пытаются разработать общую структуру распределенной координации без единой проблемы, чтобы разработчики могли сосредоточиться на обработке бизнес-логики.

На самом деле есть интересный анекдот о названии проекта «ZooKeeper». На ранней стадии проекта, учитывая, что многие внутренние проекты были названы в честь животных (например, знаменитый проект Pig), инженеры Yahoo надеялись дать этому проекту имя животного. Рагху Рамакришнан, главный научный сотрудник научно-исследовательского института в то время, пошутил: «Если так пойдет и дальше, мы станем зоопарком!»Вся распределенная система Yahoo выглядит как большой зоопарк, а Zookeeper просто используется для координации распределенной среды — так родилось название Zookeeper.

1.1 Обзор ZooKeeper

ZooKeeper — это служба распределенной координации с открытым исходным кодом, а структура ZooKeeper изначально была построена на «Yahoo!» для простого и надежного способа доступа к их приложениям. Позже Apache ZooKeeper стал стандартом для организованных служб, используемых Hadoop, HBase и другими распределенными платформами. Например, Apache HBase использует ZooKeeper для отслеживания состояния распределенных данных.Цель разработки ZooKeeper — инкапсулировать эти сложные и подверженные ошибкам службы распределенной согласованности, сформировать эффективный и надежный набор примитивов и предоставить пользователям ряд простых и удобных в использовании интерфейсов.

Примитивы:Терминология операционной системы или компьютерной сети. Это процесс, который состоит из нескольких инструкций и используется для выполнения определенной функции. Неделимый · Выполнение примитива должно быть непрерывным, прерывание во время выполнения не допускается.

ZooKeeper — типичное решение для согласованности распределенных данных.Распределенные приложения могут реализовывать публикацию/подписку на данные, балансировку нагрузки, службу именования, распределенную координацию/уведомление, управление кластером, выбор мастера, распределенную блокировку и распределение на основе функций ZooKeeper, таких как очереди.

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

1.2 Расскажите о ZooKeeper в сочетании с личным использованием

В своих проектах я в основном использую ZooKeeper в качестве центра регистрации Dubbo (Dubbo официально рекомендует использовать центр регистрации ZooKeeper). Кроме того, при построении solr-кластера я использую ZooKeeper в качестве инструмента управления solr-кластером. В настоящее время ZooKeeper в основном предоставляет следующие функции: 1. Управление кластером: отказоустойчивость и балансировка нагрузки. 2. Централизованное управление конфигурационными файлами. 3. Вход в кластер.

Я лично считаю, что при использовании ZooKeeper лучше использовать кластерную версию ZooKeeper, а не автономную версию. Схема архитектуры, представленная на официальном сайте, описывает кластерную версию ZooKeeper. Обычно 3 сервера могут образовывать кластер ZooKeeper.

Почему для формирования кластера ZooKeeper лучше использовать нечетное количество серверов?

Мы знаем, что алгоритм выбора лидера в Zookeeper использует протокол Zab. Основная идея Zab заключается в том, что при успешной записи большинства серверов успешно записываются и данные задачи.

①При наличии 3 серверов разрешается повесить трубку не более чем 1 серверу.

②Если есть 4 Сервера, не более 1 Сервера также может повесить трубку.

Так как существует 3 или 4 Сервера, и максимум 1 Сервер может выйти из строя, их надежность одинакова, поэтому вы можете выбрать нечетное количество Серверов ZooKeeper и выбрать здесь 3 Сервера.

Два важных понятия о ZooKeeper

2.1 Краткое изложение важных понятий

ZooKeeper сам по себе является распределенной программой (пока выживает более половины узлов, ZooKeeper может нормально работать).
Чтобы обеспечить высокую доступность, лучше всего развертывать ZooKeeper в форме кластера, чтобы, пока большинство машин в кластере были доступны (допуская определенные сбои машин), сам ZooKeeper оставался доступным.
ZooKeeper хранит данные в памяти, что гарантирует высокую пропускную способность и низкую задержку(Но ограничения памяти, которые могут быть сохранены, не слишком велики, и это ограничение является еще одной причиной, по которой объем данных, хранящихся в znode, должен быть небольшим).
ZooKeeper отличается высокой производительностью. Особенно высокая производительность в приложениях, где операций чтения больше, чем операций записи, поскольку операции записи заставляют все серверы синхронизировать состояние.(Больше «чтений», чем «записей» — типичные сценарии для служб координации.)
ZooKeeper использует концепцию эфемерных узлов. Эфемерный узел существует до тех пор, пока сеанс клиента, создавший эфемерный узел, остается активным. И когда сеанс заканчивается, временный узел удаляется. Постоянный узел означает, что после создания ZNode, если операция удаления ZNode не выполняется активно, ZNode всегда будет сохраняться в Zookeeper.
Нижний уровень ZooKeeper фактически обеспечивает только две функции: ① управление (хранение, чтение) данными, отправленными пользовательской программой; ② предоставление службы мониторинга узла данных для пользовательской программы.

Следующие краткие описания понятий Session, Znode, version, Watcher и ACL упоминаются в Главе 4, Разделе 1 и Главе 7, Разделе 8 «От Paxos до Zookeeper». Если вам интересно, вы можете взглянуть!

2.2 Сессия

Сеанс относится к сеансу между сервером ZooKeeper и клиентом.В ZooKeeper под клиентским соединением понимается длинное TCP-соединение между клиентом и сервером.. Когда клиент запускается, он сначала устанавливает TCP-соединение с сервером.С первого установления соединения начинается жизненный цикл клиентской сессии.Через это соединение клиент может поддерживать действующий сеанс с сервером посредством обнаружения пульса, также может отправлять запросы на сервер Zookeeper и получать ответы, а также может получать уведомления о событиях Watch с сервера через это соединение.СессияsessionTimeoutЗначение используется для установки тайм-аута для сеанса клиента. Когда клиентское соединение разрывается по разным причинам, таким как чрезмерная нагрузка на сервер, сбой сети или активное отключение клиента,покаsessionTimeoutЕсли вы можете переподключиться к любому серверу в кластере в течение указанного времени, сеанс, созданный ранее, все еще действителен.

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

2.3 Znode

Говоря о распределенных, мы обычно говорим, что «узел» относится к каждой машине, составляющей кластер. Однако в Zookeeper "узлы" делятся на две категории. Первая категория также относится к машинам, составляющим кластер, которые мы называем машинными узлами; вторая категория относится к единицам данных в модели данных, которые мы называем данными. , Узлы один за другим ZNode.

Zookeeper хранит все данные в памяти.Модель данных представляет собой дерево Znode, а путь, разделенный косой чертой (/), представляет собой Znode, например /foo/path1. Каждый сохранит свое собственное содержимое данных, а также ряд атрибутивной информации.

В Zookeeper узлы можно разделить на две категории: постоянные узлы и временные узлы. Так называемый постоянный узел означает, что после создания ZNode, если операция удаления ZNode не выполняется активно, ZNode всегда будет сохраняться в Zookeeper. Временная нода отличается, ее жизненный цикл привязан к сеансу клиента, по истечении которого все временные ноды, созданные клиентом, будут удалены.Кроме того, ZooKeeper позволяет пользователям добавлять к каждому узлу специальное свойство:SEQUENTIAL.Как только узел помечен этим атрибутом, Zookeeper автоматически добавит целое число к его имени узла при его создании.Это целое число является автоматически увеличивающимся числом, поддерживаемым родительским узлом.

Версия 2.4

Как мы упоминали ранее, каждый ZNode Zookeeper будет хранить данные, и, соответствующий каждому ZNode, Zookeeper будет поддерживать файл с именемStatStat записывает три версии данных этого ZNode, а именно версию (версию текущего ZNode), cversion (версию текущего дочернего узла ZNode) и cversion (версию ACL текущего ZNode).

2.5 Watcher

Наблюдатель (прослушиватель событий) — очень важная функция в Zookeeper. Zookeeper позволяет пользователям регистрировать некоторых наблюдателей на указанных узлах, и когда происходят определенные события, сервер ZooKeeper уведомляет заинтересованных клиентов о событиях.Этот механизм является важной функцией Zookeeper для реализации распределенных служб координации.

2.6 ACL

Zookeeper использует стратегию ACL (AccessControlLists) для управления разрешениями, аналогично управлению разрешениями в файловой системе UNIX. Zookeeper определяет следующие пять разрешений.

В частности, следует отметить, что два разрешения, CREATE и DELETE, являются контролем разрешений для дочерних узлов.

Три особенности ZooKeeper

Последовательная согласованность:Запросы на транзакции от одного и того же клиента в конечном итоге будут применяться к ZooKeeper в строгом порядке.
Атомарность:Применение результатов обработки всех запросов транзакций на всех машинах всего кластера является консистентным, то есть либо все машины всего кластера успешно применили определенную транзакцию, либо ни одна из них не была применена.
Единый системный образ:Независимо от того, к какому серверу ZooKeeper подключается клиент, он видит одну и ту же модель данных на стороне сервера.
надежность:После применения запроса на изменение результат изменения сохраняется до тех пор, пока не будет перезаписан следующим изменением.

Четыре цели дизайна ZooKeeper

4.1 Простая модель данных

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

4.2 Создаваемые кластеры

Чтобы обеспечить высокую доступность, лучше всего развертывать ZooKeeper в форме кластера, чтобы, пока большинство машин в кластере были доступны (что может выдержать определенный сбой машины), сам zookeeper оставался доступным.Когда клиент использует ZooKeeper, ему необходимо знать список машин кластера и использовать службу, устанавливая TCP-соединение с машиной в кластере.Клиент использует это TCP-соединение для отправки запросов, получения результатов, получения событий прослушивания и отправлять пакеты сердцебиения. Если соединение аварийно разорвано, клиент может подключиться к другому компьютеру.

Схема архитектуры, официально предоставленная ZooKeeper:

Каждый сервер на приведенном выше рисунке представляет собой сервер, на котором установлена служба Zookeeper. Серверы, входящие в состав службы ZooKeeper, поддерживают текущее состояние сервера в памяти, и каждый сервер взаимодействует друг с другом. Консистентность данных поддерживается между кластерами через протокол Zab (Zookeeper Atomic Broadcast).

4.3 Последовательный доступ

Каждому запросу на обновление от клиента ZooKeeper присваивает глобально уникальный добавочный номер, который отражает последовательность всех транзакционных операций.Приложения могут использовать эту функцию ZooKeeper для реализации примитивов синхронизации более высокого уровня. Этот номер также называется отметкой времени — zxid (идентификатор транзакции Zookeeper).

4.4 Высокая производительность

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

Введение в кластерную роль Five ZooKeeper

Наиболее типичный режим кластера: режим Master/Slave (активный-резервный режим). В этом режиме главный сервер обычно выступает в качестве главного сервера для предоставления услуг записи, а другие подчиненные серверы получают последние данные от главного сервера с сервера для предоставления услуг чтения посредством асинхронной репликации.

но,В ZooKeeper не выбрана традиционная концепция Master/Slave, но введены три роли: Leader, Follower и Observer.. Как показано ниже

Все машины в кластере ZooKeeper выбирают машину с именем «Лидер» в процессе выбора Лидера, и Лидер может предоставлять услуги записи и чтения для клиентов. За исключением Лидера, Последователи и Наблюдатели могут предоставлять только услуги чтения. Единственная разница между ведомым и наблюдателем заключается в том, что машина наблюдателя не участвует в процессе выбора лидера, а также не участвует в стратегии операции записи «более половины успеха записи», поэтому машина наблюдателя может улучшить производительность чтения кластера без влияния на производительность записи.

Six ZooKeeper, протокол ZAB и алгоритм Paxos

6.1 Протокол ZAB и алгоритм Paxos

Алгоритм Paxos можно назвать душой ZooKeeper. Однако ZooKeeper не полностью использует алгоритм Paxos, а использует протокол ZAB в качестве основного алгоритма для обеспечения согласованности данных. Кроме того, в официальной документации ZooKeeper также указано, что протокол ZAB не является алгоритмом общего распределенного консенсуса, как алгоритм Paxos, а является восстанавливаемым после сбоя алгоритмом рассылки атомарных сообщений, специально разработанным для ZooKeeper.

6.2 Введение в протокол ZAB

Протокол ZAB (ZooKeeper Atomic Broadcast) — это атомарный широковещательный протокол, специально разработанный для службы распределенной координации ZooKeeper для поддержки восстановления после сбоев. В ZooKeeper он в основном полагается на протокол ZAB для достижения согласованности распределенных данных.На основе этого протокола ZooKeeper реализует системную архитектуру режима ведущий-резервный для поддержания согласованности данных между репликами в кластере.

6.3 Два основных режима протокола ZAB: восстановление после сбоя и широковещательная рассылка сообщений

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

Когда более половины подчиненных серверов в кластере завершили синхронизацию состояния с ведущим сервером, вся сервисная структура может перейти в режим широковещательной рассылки сообщений.При запуске и добавлении в кластер сервера, также соответствующего ZAB-протоколу, если в кластере уже есть сервер-лидер, отвечающий за рассылку сообщений, вновь добавленный сервер осознанно перейдет в режим восстановления данных: Найдите сервер, на котором находится лидер, синхронизируют с ним данные, а затем вместе участвуют в процессе рассылки сообщения. Как упоминалось во введении выше, ZooKeeper позволяет обрабатывать запросы транзакций только одному серверу Leader. После того, как ведущий сервер получит запрос транзакции клиента, он сгенерирует соответствующее предложение транзакции и инициирует цикл широковещательного протокола; и если другие машины в кластере получат запрос транзакции клиента, эти серверы, не являющиеся ведущими, сначала перенаправят запрос транзакции. на сервер Лидер.

оПротокол ZAB и алгоритм PaxosСтолько всего нужно сказать и понять, честно говоря, автору не очень понятны конкретные принципы и процесс реализации этих двух братьев. Рекомендую прочитать следующие две статьи:

Графический протокол соответствия Paxos:

http://blog.xiaohansong.com/2016/09/30/Paxos/
Анализ протокола Zookeeper ZAB:

http://blog.xiaohansong.com/2016/08/25/zab/

О том, как использовать zookeeper для реализации распределенных блокировок, вы можете прочитать в следующей статье:

Анализ протокола Zookeeper ZAB:

https://blog.csdn.net/qiangcuo6087/article/details/79067136

Шесть резюме

Прочитав эту статью, вы, должно быть, узнали из① Происхождение ZooKeeper. -> ②Что такое ZooKeeper.-> ③ Некоторые важные концепции ZooKeeper(Сессия (сеанс), Znode, версия, Watcher, ACL ->④Возможности ZooKeeper. -> ⑤ Цель дизайна ZooKeeper.-> ⑥ Введение в роли кластера ZooKeeper(лидер, последователь и наблюдатель три роли) ->⑦ Протокол ZooKeeper, ZAB и алгоритм Paxos.Эти семь пунктов понимает ZooKeeper.

Ссылаться на

«От Паксоса до смотрителя зоопарка»
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ProjectDescription
https://cwiki.apache.org/confluence/display/ZOOKEEPER/Index
https://www.cnblogs.com/raphael5200/p/5285583.html
https://zhuanlan.zhihu.com/p/30024403

прошлоеЧудеснообзор

Хорошая статья! должно понравиться