1. Что такое зоопарк
ZooKeeper — это программное обеспечение, предоставляющее согласованные услуги для распределенных приложений.Предоставляемые функции включают в себя: обслуживание конфигурации, службу доменных имен, распределенную синхронизацию, групповую службу и т. д.
Его ядро: файловая система + механизм уведомлений
2. Важные особенности
- Лидер (Leader), группа последователей (Follower)
- в кластереПока выживает более половины узлов, кластер Zookeeper может нормально обслуживать
- Глобальная согласованность данных, каждый сервер сохраняет идентичную копию, независимо от того, к какому серверу подключается клиент, полученные данные непротиворечивы
- Запросы на обновление выполняются последовательно, и запросы от одного и того же клиента выполняются последовательно
- Обновление данныхатомарность, обновление данных выполняется успешно или не удается
- В режиме реального времени, в пределах определенного временного диапазона, клиент может считывать последние данные
3. Структура данных
Структура модели данных Zookeeper аналогичнаФайловые системы Unix похожи, в целом можно рассматривать какдерево, каждый узел называется ZNode. Каждый ZNode может хранить по умолчанию1 МБ данных, каждый ZNode может пройти свойуникальный идентификатор пути.
4. Сценарии применения (※)
- Распределенная блокировка
- Регистрация и обнаружение службы
- Используя Znode и Watcher, можно добиться регистрации и обнаружения распределенных сервисов. Наиболее известным приложением является распределенная RPC-инфраструктура Dubbo от Ali.
- Делитесь конфигурацией и информацией о состоянии
- Codis (стручок гороха), распределенное решение Redis, использует Zookeeper для хранения таблицы маршрутизации данных и метаинформации узлов codis-proxy. При этом команды, инициированные codis-config, будут синхронизированы с каждым уцелевшим codis-proxy через ZooKeeper.
5. Механизм выборов (※)
5.1 Полумеханизм (протокол paxos)
Более половины машин в кластере живы и кластер доступен, поэтому Zookeeper подходит для установки нечетного количества серверов
5.2 Внутренние выборы
Самый прямой способ выбрать мастер в распределенной системе - это напрямую выбрать один узел кластера в качестве лидера, а другие узлы - в качестве последователей.Одна из возникающих при этом проблем заключается в том, что, если умирает ведущий узел, умирает весь кластер. Должен быть алгоритм для автоматического выбора главного узла.Если ведущий узел зависает, главный узел выбирается из узлов-последователей.
1. Выборы лидера
Максимальный ZXID — это номер последней транзакции, локальный для узла, включая две части: эпоху и количество. Эпоха означает эпоху, которая эквивалентна сроку, когда алгоритм Raft выбирает лидера.Определяет текущий цикл лидера.После каждого выбора нового сервера-лидера будет генерироваться новая эпоха.
- Все узлы находятся всостояние, каждый, в свою очередь, инициирует голосование, и голосование содержит свой собственный идентификатор сервера и идентификатор последней транзакции (ZXID).
- Если вы обнаружите, что чужой ZXID больше вашего, то есть данные новее ваших, то повторно инициируйте голосование и проголосуйте за ту ноду, которой принадлежит самый большой из известных ZXID.
- После каждого голосования сервер будет подсчитывать количество голосов, чтобы определить, получил ли узел голос.больше половиныголосование. Если такой узел существует, он станет квази-лидером и его состояние изменится на «Ведущий». Статус других узлов изменится на Отслеживание.
2. Фаза обнаружения
- Чтобы предотвратить некоторые непредвиденные ситуации, такие как ситуация, когда на предыдущем этапе генерируются несколько лидеров по сетевым причинам.
- Лидер проводит мозговой штурм и получает последние значения эпохи, отправленные всеми Последователями. Лидер выбирает самую большую эпоху, добавляет 1 на основе этого значения и создает новую эпоху для распределения между каждым Последователем.
- После того, как каждый ведомый получает новую эпоху, он возвращает ACK лидеру с их соответствующим наибольшим ZXID и историческим журналом транзакций. Лидер выбирает наибольший ZXID и обновляет свой собственный журнал истории.
3. Фаза синхронизации Синхронизация
Последний исторический журнал транзакций, собранный лидером, синхронизируется со всеми подписчиками в кластере. только тогда, когдаПоловина подписчиков успешно синхронизируются, этот квазилидерСтать официальным Лидером.
Шесть, внутренняя структура ZNode
6.1 Тип узла
Постоянный: после отключения клиента и сервера созданный узел не удаляется.
Краткосрочная эфемерность: после отключения клиента и сервера созданный узел удаляется сам по себе.
Кроме того, он делится на упорядоченный и неупорядоченный. При создании упорядоченного узла имя узла будет автоматически увеличиваться на серийный номер.
$ create -s /test/no1 "no1"
Created /test/no10000000000
6.2 Внутренняя структура
- данные: информация о данных, хранящаяся в ZNode, максимальный объем данных каждого узла не превышает 1 МБ.
- ACL (список контроля доступа): запишите права доступа, кто или какой IP может получить доступ к этому узлу
- дочерний: дочерний узел текущего узла
- stat: различные метаданные, такие как идентификатор транзакции, номер версии, отметка времени, размер и т. д.
- czxid - zxid, вызвавший создание этого znode, zxid транзакции, создавшей узел
- ctime - количество миллисекунд, в течение которых был создан znode
- mzxid - последний обновленный zxid znode
- mtime - миллисекунды с момента последнего изменения znode
- pZxid-znode Последний обновленный дочерний узел zxid
- cversion - номер изменения дочернего узла znode, время модификации дочернего узла znode 7)dataversion - номер изменения данных znode
- aclVersion - номер изменения списка контроля доступа znode
- ephemeralOwner — если это эфемерный узел, это идентификатор сеанса владельца znode. 0, если не эфемерный узел
- dataLength - длина данных znode
- numChildren - количество детей znode
Семь, принцип монитора (※)
| клиент | Сервер |
|---|---|
| Основной процесс | |
| Создание клиента ZK создаст коммуникационный поток подключения к сети connet и поток прослушивания прослушивателя. | |
| Отправьте зарегистрированные события прослушивателя на сервер Zookeeper через поток подключения. | |
| Добавить событие прослушивания в список зарегистрированных слушателей | |
| Прислушивайтесь к изменениям данных или пути и отправляйте сообщение прослушивателю | |
| Поток слушателя внутренне вызывает метод процесса |
Восемь, общий мониторинг
- Увеличение или уменьшение дочерних узлов (пример ниже)
- Изменения данных узла
Девять, процесс записи данных
- Клиент отправляет запрос на запись данных любому ведомому устройству.
- Последователь пересылает запрос на запись данных ведущему.
- Лидер использует двухэтапный метод отправки и сначала отправляет сообщение о предложении подписчикам.
- Последователь получает сообщение Propose и после успешной записи журнала возвращает сообщение ACK ведущему.
- Лидер получает более половины сообщений ACK, сообщает об успехе клиенту и рассылает запрос на фиксацию подписчикам.
10. Порядок
Подключение клиента
zkcli -server host:port
create [-s] [-e] path data acl
$ create /test "data"
Created /test
get path [watch]watch относится к тому, следует ли контролировать
[zk: 10.96.86.22:2181(CONNECTED) 10] get /test
data
cZxid = 0x10
ctime = Mon Feb 25 16:34:23 CST 2019
mZxid = 0x10
mtime = Mon Feb 25 16:34:23 CST 2019
pZxid = 0x10
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 4
numChildren = 0
Ссылаться на
От Paxos до ZooKeeper Classic
один,Знакомство с основами зоопарка