Zookeeper - Основы

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

Architecture
Иерархическое пространство имен
Session
Watches

Архитектура ZooKeeper

Взгляните на следующую диаграмму. Он изображает «архитектуру клиент-сервер» ZooKeeper.

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

Часть	Описание
Клиент	Клиенты, один из узлов в нашем кластере распределенных приложений, получают доступ к информации с сервера. В течение определенного интервала времени каждый клиент отправляет сообщение на сервер, чтобы сервер знал, что клиент жив. Точно так же сервер отправляет подтверждение, когда клиент подключается. Если от подключенного сервера нет ответа, клиент автоматически перенаправляет сообщение на другой сервер.
Сервер	Сервер, один из узлов в нашем ансамбле ZooKeeper, предоставляет все услуги клиентам. Дает подтверждение клиенту, чтобы сообщить, что сервер жив.
Ансамбль	Группа серверов ZooKeeper. Минимальное количество узлов, необходимое для формирования ансамбля, - 3.
Лидер	Узел сервера, который выполняет автоматическое восстановление в случае отказа любого из подключенных узлов. Лидеры выбираются при запуске службы.
Последователь	Узел сервера, который следует инструкции лидера.

Иерархическое пространство имен

На следующей диаграмме изображена древовидная структура файловой системы ZooKeeper, используемой для представления памяти. Узел ZooKeeper упоминается какznode. Каждый znode идентифицируется именем и отделяется последовательностью путей (/).

На схеме сначала у вас есть корень znodeразделены по "/". Под root у вас есть два логических пространства именconfig и workers.
В config пространство имен используется для централизованного управления конфигурацией и workers пространство имен используется для именования.
Под configпространство имен, каждый znode может хранить до 1 МБ данных. Это похоже на файловую систему UNIX, за исключением того, что родительский узел znode также может хранить данные. Основная цель этой структуры - хранить синхронизированные данные и описывать метаданные znode. Эта структура называетсяZooKeeper Data Model.

Каждый znode в модели данных ZooKeeper поддерживает statструктура. Стат просто предоставляетmetadataзнод. Он состоит из номера версии, списка управления действиями (ACL), метки времени и длины данных.

Version number- Каждый znode имеет номер версии, что означает, что каждый раз, когда данные, связанные с znode, изменяются, соответствующий номер версии также будет увеличиваться. Использование номера версии важно, когда несколько клиентов zookeeper пытаются выполнять операции над одним и тем же узлом.
Action Control List (ACL)- ACL - это в основном механизм аутентификации для доступа к znode. Он управляет всеми операциями чтения и записи znode.
Timestamp- Timestamp представляет время, прошедшее с момента создания и изменения znode. Обычно выражается в миллисекундах. ZooKeeper идентифицирует каждое изменение znodes из «ID транзакции» (zxid).Zxid уникален и поддерживает время для каждой транзакции, так что вы можете легко определить время, прошедшее от одного запроса до другого.
Data length- Общий объем данных, хранящихся в znode, - это длина данных. Вы можете хранить не более 1 МБ данных.

Типы знодей

Z-узлы подразделяются на постоянные, последовательные и эфемерные.

Persistence znode- Постоянный znode остается живым даже после отключения клиента, создавшего этот конкретный znode. По умолчанию все z-узлы являются постоянными, если не указано иное.
Ephemeral znode- Эфемерные znodes активны, пока клиент жив. Когда клиент отключается от ансамбля ZooKeeper, эфемерные z-узлы удаляются автоматически. По этой причине только эфемерные znodes не могут иметь потомков. Если удален эфемерный znode, то следующий подходящий узел займет его позицию. Эфемерные зоды играют важную роль в выборах Лидера.
Sequential znode- Последовательные z-узлы могут быть постоянными или эфемерными. Когда новый znode создается как последовательный znode, ZooKeeper устанавливает путь к znode, добавляя 10-значный порядковый номер к исходному имени. Например, если znode с путем/myapp создается как последовательный znode, ZooKeeper изменит путь к /myapp0000000001и установите следующий порядковый номер как 0000000002. Если два последовательных znode создаются одновременно, то ZooKeeper никогда не использует один и тот же номер для каждого znode. Последовательные z-узлы играют важную роль в блокировке и синхронизации.

Сессии

Сеансы очень важны для работы ZooKeeper. Запросы в сеансе выполняются в порядке FIFO. Как только клиент подключается к серверу, будет установлен сеанс иsession id закрепляется за клиентом.

Клиент отправляет heartbeatsчерез определенный интервал времени, чтобы сеанс оставался действительным. Если ансамбль ZooKeeper не получает контрольные сообщения от клиента в течение периода, превышающего период (тайм-аут сеанса), указанный при запуске службы, он решает, что клиент умер.

Таймауты сеанса обычно выражаются в миллисекундах. Когда сеанс завершается по какой-либо причине, эфемерные z-узлы, созданные во время этого сеанса, также удаляются.

Часы

Часы - это простой механизм, позволяющий клиенту получать уведомления об изменениях в ансамбле ZooKeeper. Клиенты могут устанавливать часы при чтении определенного znode. Часы отправляют уведомление зарегистрированному клиенту при любом изменении znode (на котором регистрируется клиент).

Изменения Znode - это модификация данных, связанных с znode, или изменения в дочерних znode. Часы запускаются только один раз. Если клиент снова хочет получить уведомление, это необходимо сделать с помощью другой операции чтения. По истечении сеанса подключения клиент будет отключен от сервера, и связанные с ним часы также будут удалены.