Zookeeper — Основы

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

• Архитектура
• Иерархическое пространство имен
• сессия
• Часы

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

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

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

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

Точно так же сервер отправляет подтверждение, когда клиент соединяется. Если нет ответа от подключенного сервера, клиент автоматически перенаправляет сообщение на другой сервер.

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

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

• На диаграмме сначала у вас есть корневой узел, разделенный символом «/». Под root у вас есть два логических пространства имен config и рабочие .

• Пространство имен config используется для централизованного управления конфигурацией, а пространство имен рабочих используется для именования.

• В пространстве имен config каждый znode может хранить до 1 МБ данных. Это похоже на файловую систему UNIX за исключением того, что родительский znode также может хранить данные. Основное назначение этой структуры — хранить синхронизированные данные и описывать метаданные znode. Эта структура называется моделью данных ZooKeeper .

На диаграмме сначала у вас есть корневой узел, разделенный символом «/». Под root у вас есть два логических пространства имен config и рабочие .

Пространство имен config используется для централизованного управления конфигурацией, а пространство имен рабочих используется для именования.

В пространстве имен config каждый znode может хранить до 1 МБ данных. Это похоже на файловую систему UNIX за исключением того, что родительский znode также может хранить данные. Основное назначение этой структуры — хранить синхронизированные данные и описывать метаданные znode. Эта структура называется моделью данных ZooKeeper .

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

• Номер версии — у каждого znode есть номер версии, что означает, что каждый раз, когда данные, связанные с znode, изменяются, его соответствующий номер версии также увеличивается. Использование номера версии важно, когда несколько клиентов zookeeper пытаются выполнить операции на одном и том же znode.

• Список управления действиями (ACL) — ACL — это механизм аутентификации для доступа к znode. Он управляет всеми операциями чтения и записи znode.

• Timestamp — Timestamp представляет время, прошедшее с момента создания и модификации znode. Обычно он представлен в миллисекундах. ZooKeeper идентифицирует каждое изменение в znodes из «ID транзакции» (zxid). Zxid уникален и поддерживает время для каждой транзакции, так что вы можете легко определить время, прошедшее от одного запроса к другому.

• Длина данных — общий объем данных, хранящихся в znode, является длиной данных. Вы можете хранить максимум 1 МБ данных.

Номер версии — у каждого znode есть номер версии, что означает, что каждый раз, когда данные, связанные с znode, изменяются, его соответствующий номер версии также увеличивается. Использование номера версии важно, когда несколько клиентов zookeeper пытаются выполнить операции на одном и том же znode.

Список управления действиями (ACL) — ACL — это механизм аутентификации для доступа к znode. Он управляет всеми операциями чтения и записи znode.

Timestamp — Timestamp представляет время, прошедшее с момента создания и модификации znode. Обычно он представлен в миллисекундах. ZooKeeper идентифицирует каждое изменение в znodes из «ID транзакции» (zxid). Zxid уникален и поддерживает время для каждой транзакции, так что вы можете легко определить время, прошедшее от одного запроса к другому.

Длина данных — общий объем данных, хранящихся в znode, является длиной данных. Вы можете хранить максимум 1 МБ данных.

Типы Знодес

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

• Постоянство znode — Постоянство znode живо даже после того, как клиент, который создал этот конкретный znode, был отключен. По умолчанию все узлы являются постоянными, если не указано иное.

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

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

Постоянство znode — Постоянство znode живо даже после того, как клиент, который создал этот конкретный znode, был отключен. По умолчанию все узлы являются постоянными, если не указано иное.

Ephemeral znode — эфемерные znode активны, пока клиент не жив. Когда клиент отключается от ансамбля ZooKeeper, тогда эфемерные узлы удаляются автоматически. По этой причине только эфемерные узлы не могут иметь детей дальше. Если эфемерный znode удален, то следующий подходящий узел займет свою позицию. Эфемерные зводы играют важную роль в выборах лидера.

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

сессии

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

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

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

Часы

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

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