Привет всем, я«Продвинутые внутренние технологии»Автор, подросток, обожающий технику.
1. Введение
Я считаю, что каждый должен быть знаком с ZooKeeper. Но вы действительно понимаете, в чем польза ZooKeeper? Если кто-то/интервьюер попросит вас рассказать ему о ZooKeeper, как далеко вы сможете ответить?
Возьми, к примеру, себя! Когда я сам использовал Dubbo для распределенных проектов, я использовал ZooKeeper в качестве реестра. Чтобы гарантировать синхронный доступ распределенной системы к определенному ресурсу, я также использовал ZooKeeper для выполнения распределенных блокировок. Кроме того, когда я изучал Kafka, я знал, что многие функции Kafka зависят от ZooKeeper.
Несколько дней назад, обобщая опыт проекта, я вдруг задался вопросом, что же такое ZooKeeper? После долгих раздумий у меня в голове всплывает лишь несколько слов:
- ZooKeeper можно использовать как реестр, распределенные блокировки;
- ZooKeeper является членом экосистемы Hadoop;
- При построении кластера ZooKeeper лучше всего использовать нечетное количество серверов.
Видно, что мое понимание ZooKeeper поверхностно.
Поэтому в этой статье я надеюсь показать вам немного больше о ZooKeeper. Если вы еще не изучили ZooKeeper, то эта статья станет вашей ступенькой на пути к ZooKeeper. Если вы знакомы с ZooKeeper, эта статья вернет вас к некоторым основным понятиям ZooKeeper.
Кроме того, в этой статье будут рассмотрены не только некоторые концепции ZooKeeper, но и следующие статьи познакомят вас с использованием общих команд ZooKeeper и использованием Apache Curator в качестве клиента ZooKeeper.
Если в статье есть необходимость в доработке и доработке, пожалуйста, укажите это в области комментариев и продвигайтесь вперед вместе!
2. Введение в ZooKeeper
2.1. Происхождение ZooKeeper
Прежде чем официально представить ZooKeeper, давайте взглянем на происхождение ZooKeeper, что довольно интересно.
Ниже приведен отрывок из главы 4, раздела 1 «От Паксиса до ZooKeeper», я рекомендую вам прочитать его:
ZooKeeper был разработан исследовательской группой Yahoo Research. В то время исследователи обнаружили, что многие крупномасштабные системы в Yahoo в основном должны были полагаться на аналогичную систему для распределенной координации, но эти системы часто имели распределенные одноточечные проблемы. Поэтому разработчики Yahoo попытались разработать общую структуру распределенной координации без единой проблемы, чтобы разработчики могли сосредоточиться на обработке бизнес-логики.
На самом деле есть интересный анекдот о названии проекта «ZooKeeper». На ранней стадии проекта, учитывая, что многие внутренние проекты были названы в честь животных (например, знаменитый проект Pig), инженеры Yahoo надеялись дать этому проекту имя животного. Рагху Рамакришнан, главный научный сотрудник научно-исследовательского института в то время, пошутил: «Если так пойдет и дальше, мы станем здесь зоопарком!» Если сложить воедино вышеупомянутые компоненты, вся распределенная система Yahoo выглядит как большой зоопарк, а ZooKeeper как раз используется для координации распределенной среды — так родилось название ZooKeeper.
2.2. Обзор ZooKeeper
ZooKeeper является открытым исходным кодомСлужба распределенной координации, цель его разработки — инкапсулировать эти сложные и подверженные ошибкам службы распределенной согласованности, сформировать эффективный и надежный набор примитивов и предоставить пользователям ряд простых и удобных в использовании интерфейсов.
Примитивы:Терминология операционной системы или компьютерной сети. Это процесс, который состоит из нескольких инструкций и используется для выполнения определенной функции. Неделимый · Выполнение примитива должно быть непрерывным, прерывание во время выполнения не допускается.
ZooKeeper предоставляет нам высокодоступное, высокопроизводительное и стабильное решение для обеспечения согласованности распределенных данных, которое обычно используется для реализации публикации/подписки на данные, балансировки нагрузки, служб именования, распределенной координации/уведомления, управления кластером, выбора мастера и таких функций, как как распределенные блокировки и распределенные очереди.
Кроме того,ZooKeeper хранит данные в памяти, и производительность отличная. Особенно высокая производительность в приложениях, где операций чтения больше, чем операций записи, поскольку операции записи заставляют все серверы синхронизировать состояние. (Больше «чтений», чем «записей» — типичные сценарии для служб координации).
2.3 Функции ZooKeeper
- Последовательная согласованность:Запросы на транзакции от одного и того же клиента в конечном итоге будут применяться к ZooKeeper в строгом порядке.
- Атомарность:Применение результатов обработки всех запросов транзакций на всех машинах всего кластера является консистентным, то есть либо все машины всего кластера успешно применили определенную транзакцию, либо ни одна из них не была применена.
- Единый системный образ:Независимо от того, к какому серверу ZooKeeper подключается клиент, он видит одну и ту же модель данных на стороне сервера.
- надежность:После применения запроса на изменение результат изменения сохраняется до тех пор, пока не будет перезаписан следующим изменением.
2.4 Типичные сценарии применения ZooKeeper
В обзоре ZooKeeper мы рассказали, что он обычно используется для реализации таких функций, как публикация/подписка на данные, балансировка нагрузки, службы именования, распределенная координация/уведомление, управление кластером, выбор мастера, распределенные блокировки и распределенные очереди.
Вот три типичных сценария применения, о которых стоит поговорить:
- Распределенная блокировка: распределенная блокировка получается путем создания уникального узла, и блокировка снимается, когда сторона, получившая блокировку, выполняет соответствующий код или кладет трубку.
- служба имен: глобальный уникальный идентификатор может быть сгенерирован через последовательные узлы ZooKeeper.
- Данные публиковать/подписываться:пройти черезНаблюдательный механизмПубликация/подписка на данные может быть легко реализована. Когда вы публикуете данные на узлах, где ZooKeeper отслеживается, другие машины могут динамически обновлять конфигурацию, отслеживая изменения узлов в ZooKeeper.
На самом деле реализация этих функций в основном выигрывает от способности ZooKeeper сохранять данные, но ZooKeeper не подходит для хранения больших объемов данных, требующих внимания.
2.5 Какие известные проекты с открытым исходным кодом используют ZooKeeper?
- Kafka: ZooKeeper в основном обеспечивает регистрацию брокера и темы, а также балансировку нагрузки нескольких разделов для Kafka.
- Hbase: ZooKeeper предоставляет Hbase такие функции, как обеспечение того, чтобы весь кластер имел только одного Мастера, а также сохранение и предоставление информации о состоянии региона-сервера (независимо от того, находится ли он в сети или нет).
- Hadoop: ZooKeeper обеспечивает поддержку высокой доступности для Namenode.
3. Интерпретация важных концепций ZooKeeper
Поин: Возьмите небольшую книгу, следующее содержание очень важно!
3.1 Модель данных
Модель данных ZooKeeper использует иерархическую структуру дерева с несколькими ответвлениями, и каждый узел может хранить данные, которые могут быть числами, строками или двоичными последовательностями. и. У каждого узла также может быть N дочерних узлов, а верхний уровень — это корневой узел, представленный знаком «/». Каждый узел данных вызывается в ZooKeeperznode, который является наименьшей единицей данных в ZooKeeper. Кроме того, каждый znode имеет уникальный идентификатор пути.
Подчеркните одно предложение:ZooKeeper в основном используется для координации услуг, а не для хранения бизнес-данных, поэтому не размещайте относительно большие данные на znodes.Верхний предел, указанный ZooKeeper, заключается в том, что максимальный размер данных каждого узла составляет 1M.
Более наглядно это видно из следующего рисунка: Метод определения пути к узлу ZooKeeper очень похож на путь к файловой системе Unix, который представлен серией путей, разделенных косой чертой «/», и разработчики могут записывать данные в этот узел. вы также можете создавать дочерние узлы ниже узла. Мы представим эти операции позже.
3.2 znode (узел данных)
Введя древовидную модель данных ZooKeeper, мы знаем, что каждый узел данных вызывается в ZooKeeper.znode, который является наименьшей единицей данных в ZooKeeper. Данные, которые вы хотите сохранить, размещаются на нем, что является концепцией, с которой вам часто приходится соприкасаться при использовании ZooKeeper.
3.2.1 4 типа znode
Обычно мы делим znodes на 4 категории:
- Постоянный (PERSISTENT) узел: после создания он сохраняется, даже если кластер ZooKeeper выходит из строя, до тех пор, пока он не будет удален.
- Эфемерный узел: время жизни эфемерного узла такое же, какСеанс клиента (сеанс)граница,Когда сеанс исчезает, узел исчезает. и,Временные узлы могут быть только листовыми узлами., не может создавать дочерние узлы.
-
Узел постоянной последовательности (PERSISTENT_SEQUENTIAL): В дополнение к характеристикам постоянных (PERSISTENT) узлов имена дочерних узлов также являются последовательными. Например
/node1/app0000000001,/node1/app0000000002. - Узел временной последовательности (EPHEMERAL_SEQUENTIAL): В дополнение к характеристикам временных (EPHEMERAL) узлов имена дочерних узлов также являются последовательными.
3.2.2 Структура данных znode
Каждый znode состоит из 2-х частей:
- stat:информация о статусе
- data: конкретное содержание данных, хранящихся на узле
Как показано ниже, я использую команду get для получения содержимого узла dubbo в корневом каталоге. (Команда get описана ниже).
[zk: 127.0.0.1:2181(CONNECTED) 6] get /dubbo
# 该数据节点关联的数据内容为空
null
# 下面是该数据节点的一些状态信息，其实就是 Stat 对象的格式化输出
cZxid = 0x2
ctime = Tue Nov 27 11:05:34 CST 2018
mZxid = 0x2
mtime = Tue Nov 27 11:05:34 CST 2018
pZxid = 0x3
cversion = 1
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 1
Класс Stat содержит поля всей информации о состоянии узла данных, включая идентификатор транзакции-cZxid, время создания узла-ctime и количество дочерних узлов-numChildren и т. д.
Давайте посмотрим, что представляет собой информация о состоянии каждого znode! (Следующее содержание взято из «Принципа и практики распределенной согласованности от Paxos до ZooKeeper», потому что руководство действительно не очень понятно, вам нужно изучить справочные материалы!):
| информация о состоянии znode | объяснять |
|---|---|
| cZxid | создать ZXID, который является идентификатором транзакции при создании узла данных |
| ctime | create time, то есть время создания узла |
| mZxid | модифицированный ZXID, который является идентификатором транзакции при последнем обновлении узла. |
| mtime | время модификации, то есть время последнего обновления узла |
| pZxid | Идентификатор транзакции при последнем изменении списка дочерних узлов этого узла, pZxid будет обновляться только в случае изменения списка дочерних узлов, а содержимое дочернего узла не будет обновляться. |
| cversion | Номер версии дочернего узла, значение увеличивается на 1 каждый раз, когда дочерний узел текущего узла изменяется |
| dataVersion | Номер версии содержимого узла данных, который равен 0 при создании узла и увеличивается на 1 при каждом обновлении содержимого узла (независимо от того, изменяется ли содержимое). |
| aclVersion | Номер версии ACL узла, указывающий, сколько раз информация ACL узла была изменена. |
| ephemeralOwner | sessionId сеанса, который создал этот эфемерный узел; ephemeralOwner=0, если текущий узел является постоянным |
| dataLength | длина содержимого узла данных |
| numChildren | Количество дочерних узлов текущего узла |
3.3 Версия
Как мы упоминали ранее, для каждого узла ZooKeeper поддерживаетStatСтруктура данных, три связанные версии этого znode записаны в Stat:
- dataVersion: номер версии текущего znode
- cversion: версия текущего дочернего узла znode
- aclVersion: Версия ACL текущего znode.
3.4. ACL (управление доступом)
ZooKeeper использует стратегию ACL (AccessControlLists) для управления разрешениями, которая аналогична управлению разрешениями в файловых системах UNIX.
ZooKeeper предоставляет следующие пять типов разрешений для операций znode:
- CREATE: может создавать дочерние узлы
- READ: Может получать данные узла и перечислять его дочерние узлы.
- WRITE: Может устанавливать/обновлять данные узла
- DELETE: Можно удалять дочерние узлы
- ADMIN: Разрешение на установку ACL узла
Особо следует отметить, что,CREATEиDELETEОба разрешения предназначены длядочерний узелконтроль разрешений.
Для аутентификации личности предусмотрены следующие методы:
- world: По умолчанию все пользователи имеют безусловный доступ.
- auth: не использует идентификатор, представляет любого аутентифицированного пользователя.
- digest:Имя пользователя:Пароль Метод аутентификации:username:password.
- ip: Ограничить указанный ip.
3.5 Наблюдатель (слушатель событий)
Watcher (прослушиватель событий) — очень важная функция ZooKeeper. ZooKeeper позволяет пользователям регистрировать некоторых наблюдателей на указанных узлах, и когда происходят определенные события, сервер ZooKeeper уведомляет заинтересованных клиентов о событиях.Этот механизм является важной функцией ZooKeeper для реализации распределенных служб координации.
Прерывание звука: Очень полезная фича, можно записать в небольшую книжку, а последующее использование ZooKeeper в принципе неотделимо от механизма Watcher (слушателя событий).
3.6 Сессия
Сеанс можно рассматривать как длинное TCP-соединение между сервером ZooKeeper и клиентом.Благодаря этому соединению клиент может поддерживать действующий сеанс с сервером посредством обнаружения сердцебиения, а также может отправлять запросы на сервер ZooKeeper и получать ответы. получает уведомления о событиях Watcher от сервера.
Сессия имеет свойство, называемое:sessionTimeout,sessionTimeoutПредставляет период ожидания для сеанса. Когда клиентское соединение разорвано по разным причинам, таким как чрезмерная нагрузка на сервер, сбой сети или клиент активно отключает соединение, до тех пор, покаsessionTimeoutЕсли вы можете переподключиться к любому серверу в кластере в течение указанного времени, сеанс, созданный ранее, все еще действителен.
Кроме того, перед созданием сеанса для клиента сервер сначала назначаетsessionID. так какsessionIDЭто важный идентификатор сеанса ZooKeeper, и многие операционные механизмы, связанные с сеансом, основаны на этом.sessionID, так что какой бы сервер ни назначал клиентуsessionID, должно быть гарантировано уникальное в глобальном масштабе.
4. Кластер ZooKeeper
Чтобы обеспечить высокую доступность, лучше всего развертывать ZooKeeper в форме кластера, чтобы, пока большинство машин в кластере были доступны (допуская определенные сбои машин), сам ZooKeeper оставался доступным. Обычно 3 сервера могут образовывать кластер ZooKeeper. Официальная схема архитектуры ZooKeeper состоит в том, что кластер ZooKeeper предоставляет услуги внешнему миру в целом.
Каждый сервер на приведенном выше рисунке представляет собой сервер, на котором установлена служба ZooKeeper. Серверы, входящие в состав службы ZooKeeper, поддерживают текущее состояние сервера в памяти, и каждый сервер взаимодействует друг с другом. Консистентность данных поддерживается между кластерами через протокол ZAB (ZooKeeper Atomic Broadcast).
Наиболее типичный режим кластера: режим Master/Slave (активный-резервный режим). В этом режиме главный сервер обычно действует как главный сервер для предоставления услуг записи, а другие подчиненные серверы получают последние данные от главного сервера с сервера для предоставления услуг чтения посредством асинхронной репликации.
4.1 Роли кластера ZooKeeper
Однако вместо выбора традиционной концепции Master/Slave в ZooKeeper вводятся три роли: лидер, ведомый и наблюдатель. Как показано ниже
Все машины в кластере ZooKeeper проходятПроцесс избрания лидеравыбратьLeader”, Лидер может предоставлять клиенту услуги как записи, так и чтения.FollowerиObserverМожет предоставлять только услуги чтения. Единственная разница между Follower и Observer заключается в том, что машина Observer не участвует в процессе выбора лидера и не участвует в стратегии «более половины успеха записи» для операций записи, поэтому машина Observer может улучшить чтение производительность кластера, не влияя на производительность записи.
| Роль | инструкция |
|---|---|
| Leader | Предоставляет услуги чтения и записи для клиентов, отвечает за инициирование и разрешение голосования, а также обновляет состояние системы. |
| Follower | Предоставлять клиенту услугу чтения и пересылать ведущему, если это услуга записи. Участвовать в голосовании в ходе избирательного процесса. |
| Observer | Предоставьте сервер чтения для клиента и перенаправьте его ведущему, если это служба записи. Не участвует в голосовании во время избирательного процесса, а также не участвует в стратегии «успех записи более половины». Улучшите производительность чтения кластера, не влияя на производительность записи. Эта роль была добавлена в серию ZooKeeper 3.3. |
Когда на сервере-лидере возникают нештатные ситуации, такие как прерывание сети, выход из строя и перезапуск, он вступает в процесс выбора лидера, в результате которого будет выбран новый сервер-лидер.
Процесс происходит примерно так:
- Выборы лидера: узлы находятся в фазе выборов в начале. Пока один узел получает голоса более половины узлов, он может быть избран квази-лидером.
- Открытие: на этом этапе ведомые общаются с квази-лидером, синхронизируя предложения по транзакциям, недавно полученные ведомыми.
- Синхронизация (фаза синхронизации): на этапе синхронизации в основном используется последняя история предложений, полученная лидером на предыдущем этапе, для синхронизации всех реплик в кластере. После завершения синхронизации Квазилидер становится настоящим лидером.
- Трансляция (этап трансляции): На данном этапе кластер ZooKeeper может официально предоставлять услуги внешних транзакций, а лидер может транслировать сообщения. В то же время, если присоединяется новый узел, новый узел необходимо синхронизировать.
4.2 Статус сервера в кластере ZooKeeper
- LOOKING: найти лидера.
- LEADING: Состояние Лидера, соответствующий узел Лидер.
- FOLLOWING: Состояние ведомого, соответствующий узел — ведомый.
- OBSERVING: состояние наблюдателя, соответствующий узел является наблюдателем, и этот узел не участвует в выборах лидера.
4.3 Почему лучше использовать нечетное количество кластеров ZooKeeper?
После того, как кластер ZooKeeper отключит несколько серверов ZooKeeper, весь ZooKeeper по-прежнему будет доступен, если количество оставшихся серверов ZooKeeper превышает количество простоев. Если в нашем кластере n серверов ZooKeeper, то количество оставшихся служб должно быть больше n/2. Позвольте мне сначала поговорить о выводе.Допуск 2n и 2n-1 одинаков, оба n-1.Вы можете сначала подумать об этом сами, это должна быть очень простая математическая задача. Например, если у нас есть 3 сервера, то максимум 1 сервер ZooKeeper может быть отключен, а если у нас есть 4 сервера, только один может быть отключен. Если у нас 5, то максимум 2 сервера ZooKeeper могут быть отключены, а если у нас 6, то только 2 могут быть отключены.
Подводя итог, зачем добавлять этот ненужный ZooKeeper?
5. Протокол ZAB и алгоритм Paxos
Алгоритм Paxos должен быть душой ZooKeeper. Однако ZooKeeper не полностью использует алгоритм Paxos, а использует протокол ZAB в качестве основного алгоритма для обеспечения согласованности данных. Кроме того, в официальной документации ZooKeeper также указано, что протокол ZAB не является алгоритмом общего распределенного консенсуса, как алгоритм Paxos, а является восстанавливаемым после сбоя алгоритмом рассылки атомарных сообщений, специально разработанным для ZooKeeper.
5.1. Введение в протокол ZAB
Протокол ZAB (ZooKeeper Atomic Broadcast) — это атомарный широковещательный протокол, специально разработанный для службы распределенной координации ZooKeeper для поддержки восстановления после сбоев. В ZooKeeper он в основном полагается на протокол ZAB для достижения согласованности распределенных данных.На основе этого протокола ZooKeeper реализует системную архитектуру режима ведущий-резервный для поддержания согласованности данных между репликами в кластере.
5.2. Два основных режима протокола ZAB: восстановление после сбоя и широковещательная рассылка сообщений
Протокол ZAB включает два основных режима, а именно
- аварийное восстановление: когда вся сервисная структура находится в процессе запуска или когда на сервере Leader возникают сетевые прерывания, сбои, выходы и перезапуски, протокол ZAB переходит в режим восстановления и выбирает новый сервер Leader. Когда выбран новый сервер-лидер и более половины машин в кластере завершили синхронизацию состояния с сервером-лидером, протокол ZAB выйдет из режима восстановления. в,Так называемая синхронизация состояния относится к синхронизации данных, которая используется для обеспечения того, чтобы более половины машин в кластере могли поддерживать согласованное состояние данных ведущего сервера..
- широковещательное сообщение:Когда более половины подчиненных серверов в кластере завершили синхронизацию состояния с ведущим сервером, вся сервисная структура может перейти в режим широковещательной рассылки сообщений.При запуске и добавлении в кластер сервера, также соответствующего ZAB-протоколу, если в кластере уже есть сервер-лидер, отвечающий за рассылку сообщений, вновь добавленный сервер осознанно перейдет в режим восстановления данных: найдите, где лидер находится , и синхронизируют с ним данные, а затем вместе участвуют в процессе рассылки сообщений.
оПротокол ZAB и алгоритм PaxosЕсть так много вещей, которые нужно сказать и понять. Подробности можно найти в следующих двух статьях:
6. Резюме
- ZooKeeper сам по себе является распределенной программой (пока выживает более половины узлов, ZooKeeper может нормально работать).
- Чтобы обеспечить высокую доступность, лучше всего развертывать ZooKeeper в форме кластера, чтобы, пока большинство машин в кластере были доступны (допуская определенные сбои машин), сам ZooKeeper оставался доступным.
- ZooKeeper хранит данные в памяти, что гарантирует высокую пропускную способность и низкую задержку (но память ограничивает объем данных, которые можно сохранить, что является еще одной причиной сохранения небольшого объема данных, хранящихся в znodes).
- ZooKeeper отличается высокой производительностью. Это особенно заметно в приложениях, где операций чтения больше, чем операций записи, поскольку операции записи заставляют все серверы синхронизировать состояние. (Больше «чтений», чем «записей» — типичные сценарии для служб координации.)
- ZooKeeper использует концепцию эфемерных узлов. Эфемерный узел существует до тех пор, пока сеанс клиента, создавший эфемерный узел, остается активным. И когда сеанс заканчивается, временный узел удаляется. Постоянный узел означает, что после создания znode, если znode не будет активно удален, znode всегда будет храниться в ZooKeeper.
- Нижний уровень ZooKeeper фактически обеспечивает только две функции: ① Управление (хранение, чтение) данными, отправленными пользовательскими программами; ② Предоставление услуг мониторинга узлов данных для пользовательских программ.
7. Ссылка
- «Принцип и практика распределенной согласованности от Paxos до ZooKeeper»