Zookeeper - Рабочий процесс

После запуска ансамбля ZooKeeper он будет ожидать подключения клиентов. Клиенты будут подключаться к одному из узлов в ансамбле ZooKeeper. Это может быть лидер или последователь узла. Как только клиент подключен, узел назначает идентификатор сеанса конкретному клиенту и отправляет подтверждение клиенту. Если клиент не получает подтверждение, он просто пытается подключиться к другому узлу в ансамбле ZooKeeper. После подключения к узлу клиент будет регулярно отправлять тактовые импульсы на узел, чтобы убедиться, что соединение не потеряно.

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

  • Если клиент хочет сохранить данные в ансамбле ZooKeeper , он отправляет путь znode и данные на сервер. Подключенный сервер перенаправит запрос лидеру, а затем лидер повторно отправит запрос на запись всем подписчикам. Если только большинство узлов ответят успешно, запрос на запись будет выполнен успешно, и успешный код возврата будет отправлен клиенту. В противном случае запрос на запись не будет выполнен. Строгое большинство узлов называется Кворумом .

Узлы в ансамбле ZooKeeper

Давайте проанализируем эффект наличия разного количества узлов в ансамбле ZooKeeper.

  • Если у нас есть один узел , то ансамбль ZooKeeper дает сбой при сбое этого узла. Это способствует «единой точке отказа» и не рекомендуется в производственной среде.

  • Если у нас есть два узла и один узел выходит из строя, у нас также нет большинства, так как один из двух не является большинством.

  • Если у нас есть три узла и один узел выходит из строя, у нас есть большинство и так, это минимальное требование. Для ансамбля ZooKeeper обязательно иметь как минимум три узла в рабочей среде.

  • Если у нас четыре узла и два узла вышли из строя, он снова выходит из строя, и это похоже на наличие трех узлов. Дополнительный узел не служит какой-либо цели, поэтому лучше добавлять узлы в нечетные числа, например, 3, 5, 7.

Мы знаем, что процесс записи дороже, чем процесс чтения в ансамбле ZooKeeper, поскольку все узлы должны записывать одни и те же данные в свою базу данных. Таким образом, лучше иметь меньшее количество узлов (3, 5 или 7), чем иметь большое количество узлов для сбалансированной среды.

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

Ансамбль ZooKeeper
Компонент Описание
Написать Процесс записи обрабатывается ведущим узлом. Руководитель направляет запрос на запись всем узлам и ждет ответов от узлов. Если ответит половина узлов, процесс записи завершен.
Читать Чтения выполняются внутри определенного подключенного узла, поэтому нет необходимости взаимодействовать с кластером.
Реплицированная база данных Используется для хранения данных в zookeeper. Каждый znode имеет свою собственную базу данных, и каждый znode каждый раз имеет одинаковые данные с помощью согласованности.
руководитель Лидер - это Znode, который отвечает за обработку запросов на запись.
толкатель Последователи получают запросы на запись от клиентов и отправляют их руководителю znode.
Обработчик запросов Присутствует только в ведущем узле. Он управляет запросами на запись от узла-подписчика.
Атомные трансляции Отвечает за трансляцию изменений от узла-лидера на узлы-последователи.