1. Рабочий механизм зоозащитника
По сравнению с распределенными и централизованными системами у них есть много преимуществ, таких как более высокая вычислительная мощность, емкость хранилища, отсутствие единой точки отказа и другие проблемы. Однако, как обеспечить согласованность и доступность данных каждого узла, является более важным вопросом при сбоях сети и других проблемах в методе распределенного развертывания.
Затем для распределенного кластера нам нужен посредник, который может координировать и обслуживать между различными сервисами и узлами — Zookeeper.
Zookeeper понимается с точки зрения режима проектирования: это структура управления распределенными службами, разработанная на основе режима наблюдателя, она отвечает за хранение и управление данными, которые всем важны, а затем принимает регистрацию наблюдателей. изменения данных, Zookeeper будет нести ответственность за уведомление тех наблюдателей, которые уже зарегистрированы в Zookeeper, чтобы они отреагировали соответствующим образом.
2. Структура данных
Структура данных Zookeeper похожа на структуру каталогов Linux, а также похожа на дерево в структуре данных, как показано ниже:
Хранилище данных Zookeeper основано на узлах, которые называются Znodes. Эталонный метод Znode является ссылкой на путь, и каждый Znode может быть однозначно идентифицирован своим путем.
Znode содержит: данные, ссылки на дочерние узлы, права доступа и т. д., как показано ниже:
- данные: информация о данных, хранящаяся в Znode
- ACL: запишите права доступа Znode, то есть кто или какие IP могут получить доступ к узлу
- дочерний элемент: ссылка на дочерний узел текущего узла, аналогичная левому дочернему правому дочернему элементу двоичного дерева.
- stat: содержит различные метаданные Znode, такие как идентификатор транзакции, номер версии, отметку времени, размер и т. д.
stat для просмотра сведений о корневом каталоге:
[zk: localhost:2181(CONNECTED) 0] stat /
cZxid = 0x0
ctime = Thu Jan 01 08:00:00 CST 1970
mZxid = 0x0
mtime = Thu Jan 01 08:00:00 CST 1970
pZxid = 0x0
cversion = -1
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 1
3. Избирательный механизм
Кластер Zookeeper представляет собой модель «главный-множественный-подчиненный».Главный — это лидер, а подчиненный — последователь. Лидер получается путем выборов.
Кластер Zookeeper имеет следующие характеристики:
- Zookeeper: лидер (лидер), группа последователей (followers)
- Лидер отвечает за инициирование и разрешение голосования и обновление статуса системы
- Последователи используются для получения клиентских запросов и возврата результатов клиентам, а также для участия в голосовании в процессе выбора лидера.
- Пока выживет более половины узлов в кластере, кластер Zookeeper может нормально работать, поэтому Zookeeper подходит для установки нечетного количества серверов.
- Согласованные глобальные данные: каждый сервер сохраняет копию одних и тех же данных, независимо от того, к какому серверу подключается клиент, данные непротиворечивы.
- Запросы на обновление выполняются последовательно, а запросы на обновление от одного и того же клиента выполняются в том порядке, в котором они были отправлены
- Атомарность обновления данных, обновление данных либо успешно, либо нет
- В режиме реального времени, в пределах определенного временного диапазона, клиент может считывать последние данные
Выбор лидера является ключом к обеспечению согласованности распределенных данных.Когда Zookeeper входит в следующие два состояния, ему необходимо войти в выборы лидера:
- Инициализация сервера начинается
- Лидер вылетает и зависает
1. Выбор при инициализации сервера
(1) Взяв в качестве примера кластер, состоящий из трех серверов, на этапе инициализации кластера, когда сервер 1 запускается, он не может завершить выбор в одиночку; когда запускается сервер 2, две машины могут в это время взаимодействовать друг с другом, и каждая машина пытается найти лидера, поэтому войдите в состояние выборов
(2)Каждый сервер сначала голосует за себя: На начальном этапе каждый сервер голосует за себя как за лидера.Информация, содержащаяся в каждом голосовании: (myid, ZXID, эпоха).В это время голос Сервера1 равен (1, 0), а голос Сервера2 (2, 0) ), а затем каждый отправляет этот голос другим машинам в кластере.
Эпоха используется для определения того, находятся ли несколько голосов в одном и том же избирательном цикле. Это значение представляет собой последовательность автоматического увеличения на стороне сервера. После ввода нового раунда голосования значение будет увеличиваться на 1.
(3)Каждый сервер принимает голоса с каждого сервера: после того, как каждый сервер в кластере получает голосование, он сначала определяет действительность голосования, например, проверяет, является ли это текущим раундом голосования и исходит ли оно от сервера, находящегося в состоянии ПРОСМОТР.
(4)Обработка голосов. Для каждого голоса серверу необходимо PK голосов других и его собственных.Правила PK следующие:
- Сначала проверьте ZXID. Серверы с большими ZXID предпочтительны как лидеры
- Если ZXID совпадает, то сравните myid. Сервер с большим myid действует как сервер-лидер.
Для Сервера 1 его голос равен (1, 0), а голос, полученный Сервером 2, равен (2, 0).Сначала будут сравниваться ZXID двух, оба из которых равны 0, а затем будет сравниваться myid. В настоящее время myid сервера 2 является самым большим, поэтому обновите свой голос до (2, 0), а затем снова проголосуйте.Для сервера 2 ему не нужно обновлять свой голос, а просто отправляет информацию о последнем голосовании всем машинам. снова в кластере.
(5)подсчет голосов. После каждого голосования сервер будет подсчитывать информацию о голосовании, чтобы определить, получили ли более половины компьютеров одинаковую информацию о голосовании.Для Server1 и Server2 считается, что две машины в кластере приняли голосование (2, 0 ).Информация,на данный момент считается что лидер выбран.Как только лидер выбран,машина сзади автоматически становится младшим братом лидера вне зависимости от размера myid и ZXID.
(6)изменить состояние сервера. Как только лидер будет определен, каждый сервер обновит свой статус: если это ведомый, он будет изменен на СЛЕДУЮЩИЙ, а если это лидер, он будет изменен на ВЕДУЩИЙ.
2. Механизм голосования при зависании лидерского сервера
Отличие от стартапа в том, что у каждого сервера есть исторические данные.Перед выборами сервер не лидер сначала меняет состояние на состояние LOOKING, т.к. ZXID каждого сервера в процессе работы разный, и он будет переголосован как выборы при запуске.
4. Механизм мониторинга
- Сначала должен быть поток main()
- Создайте клиент Zookeeper в основном потоке, затем будут созданы два потока, один из которых отвечает за связь по сетевому соединению (connet), а другой — за прослушивание (listener).
- Отправлять зарегистрированные события прослушивателя в Zookeeper через поток подключения.
- Добавить события зарегистрированных слушателей в список зарегистрированных слушателей Zookeeper.
- Zookeeper прослушивает данные или изменения пути и отправляет это сообщение в поток прослушивателя.
- Метод process() вызывается внутри потока слушателя.
5. Приложение API
API-интерфейсы, обычно используемые Zookeeper, следующие:
create
创建节点
delete
删除节点
exists
判断节点是否存在
getData
获得一个节点的数据
setData
设置一个节点的数据
getChildren
获取节点下的所有子节点Среди них exists, getData и getChildren являются операциями чтения. Когда клиент Zookeeper запрашивает операцию чтения, он может выбрать, устанавливать ли ееWatch.
Что означает смотреть?
Мы можем понимать это как триггер, зарегистрированный на конкретном Znode. При изменении Znode, то есть при вызове методов create, delete, setData, сработает соответствующее событие, зарегистрированное на Znode, и клиент, запрашивающий Watch, получитАсинхронное уведомление.
Конкретный процесс взаимодействия выглядит следующим образом:
- Клиент вызывает метод getData, и параметр watch имеет значение true. Сервер получает запрос, возвращает данные узла и вставляет путь Znode для наблюдения и список наблюдателей в соответствующую хеш-таблицу.
- Когда наблюдаемый Znode удален, сервер просматривает хеш-таблицу, находит всех наблюдателей, соответствующих Znode, асинхронно уведомляет клиента и удаляет соответствующий ключ-значение в хеш-таблице.
6. Сценарии применения
Услуги, предоставляемые Zookeeper, включают в себя: унифицированную службу именования, унифицированное управление конфигурацией, унифицированное управление кластером, динамический онлайн и оффлайн серверных узлов, мягкую балансировку нагрузки и т. д.
Добро пожаловать в следующую общедоступную учетную запись для получения дополнительной информации о статье