Что такое зоокипер

ZooKeeper — это распределенная служба координации распределенных приложений с открытым исходным кодом. Это реализация Google Chubby с открытым исходным кодом и важный компонент Hadoop и Hbase.

В официальной документации Zookeeper рассматривается как распределенная координационная структура. Apache Hadoop Подпроект распределенного, который в основном используется для решения некоторых проблем управления данными, часто встречающихся в распределенных приложениях, таких как: служба унифицированных имен, служба синхронизации статусов, управление. кластером, распределенное управление элементами конфигурации приложения и т.д. Это программное обеспечение, которое предоставляет согласованные услуги для распределенных приложений.

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

Официальный сайт: https://zookeeper.apache.org/.

Зачем использовать Zookeeper

При развитии крупных предприятий количество услуг очень велико. Если мы хотим добавить сервис, нам нужно перезаписать файл и перезапустить весь контейнер. В результате воздействие слишком велико, а обслуживание становится очень трудным.

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

Основные понятия Zookeeper

роль кластера

Обычно в распределенной системе каждая машина, образующая кластер, имеет свою собственную роль. Наиболее типичным кластером является режим «главный/подчиненный» (режим «активный-резервный»). В этом случае все машины, которые могут выполнять операции записи, называются «главными». считает все машины, которые получают самые последние данные посредством асинхронной репликации и предоставляют услуги чтения, как подчиненные машины.

В Zookeeper эти концепции извращены. Он не следует преходящей концепции «главный/подчиненный», а вводит три роли: лидер, последователь и наблюдатель. Все машины в кластере Zookeeper выбирают машину, называемую лидером, посредством выбора лидера. Сервер-лидер предоставляет клиентам услуги чтения и записи. Помимо лидера, услуги чтения могут предоставлять и другие машины. Единственное отличие состоит в том, что Observer не участвует в процессе выбора лидера и не участвует в стратегии успеха более чем половины операций записи. Таким образом, Observer может повысить производительность кластера, не влияя на производительность записи.

сессия

Под сеансом клиента подразумевается длинное TCP-соединение между клиентом и сервером. Порт внешнего сервиса Zookeeper по умолчанию равен 2181. Когда клиент запускается, он сначала устанавливает соединение с установленным TCP-соединением. с первого подключения Вначале также начинается жизненный цикл клиентского сеанса. Благодаря этому соединению клиент может определять и поддерживать действительный сеанс с сервером. Он также может отправлять запросы на сервер Zookeeper и получать ответы. с сервера через это соединение.

Узел данных (Znode)

Говоря о распределении, «узел», который мы обычно называем, относится к каждой машине, составляющей кластер. Однако в ZooKeeper «узлы» разделены на две категории. Первая категория также относится к машинам, образующим кластер, который мы называем машинными узлами; вторая категория относится к блокам данных в модели данных, которые мы называем данными. .Узел--ZNode. ZooKeeper хранит все данные в памяти. Модель данных представляет собой дерево (дерево ZNode). Путь, разделенный косой чертой (/), представляет собой Znode, например /app/path1. Каждый ZNode сохранит свое собственное содержимое данных, а также ряд атрибутивной информации.

Версия

Мы только что упомянули,Данные хранятся на каждом Znode Zookeeper.,Для каждого ZNode,Zookeeper будет поддерживать для него структуру данных под названием Stat.,Stat записывает три данных этой версии ZNode.,Они естьversion（текущийZNodeиз Версия）、cversion (Версия текущего дочернего узла ZNode)、отвращение (ACL Версия текущего ZNode).

Наблюдатель (прослушиватель событий)

Wathcer (прослушиватель событий) — очень важная функция Zookeeper. Zookeeper позволяет пользователям регистрировать некоторые наблюдатели на назначенных узлах, и при возникновении определенных событий сервер Zookeeper уведомляет заинтересованные стороны о событии. Этот механизм является важным. функция Zookeeper для реализации служб распределенной координации.

ACL

Zookeeper использует стратегию ACL (списки контроля доступа) для управления разрешениями, которая определяет следующие пять разрешений:

• CREATE: Разрешение на создание дочерних узлов.
• ЧТЕНИЕ: разрешение на получение данных узла и списка дочерних узлов.
• WRITE: Разрешение на обновление данных узла.
• DELETE: Разрешение на удаление дочерних узлов.
• АДМИН: Установите разрешения узла ACL.

Следует отметить, что разрешения CREATE и DELETE являются элементами управления разрешениями для дочерних узлов.

Основные понятия Zookeeper

Zookeeper — это база данных на основе памяти, используемая для хранения небольших объемов данных. Данные в Zookeeper хранятся в памяти, поэтому они очень эффективны. Его метод внутреннего хранения очень похож на структуру хранения файлов, используя иерархическую структуру хранения. Но разница между ней и файловой структурой хранения в том, что каждый ее узел может хранить данные. Следует отметить, что каждый узел zk не может хранить более 1М данных. Результаты данных памяти следующие:

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

zk предоставляет только несколько простых API, но мы можем гибко использовать комбинацию этих API для достижения наших сложных бизнес-требований:

• create: Создайте новый узел, указав путь. Например, если путь создания — /A/A1/demo, демонстрационный узел будет создан под узлом A1;
• delete: удалить узел, удалить узел по пути. Если путь удаления — /A/A1/demo, демонстрационный узел под узлом A1 будет удален;
• существует: определяет, существует ли узел по указанному пути. Например, если путь — /A/A1/demo, он определит, существует ли демонстрационный узел по узлу A1;
• get: Получить значение узла по указанному пути. Например, если путь получения — /A/A1/demo, то будет получено значение демонстрационного узла по узлу A1;
• set: выполняет операцию присвоения для узла указанного пути. Например, если путь изменен на /A/A1/demo, значение демонстрационного узла под узлом A1 будет изменено;
• получить дочерние элементы: получить информацию о дочернем узле в указанном узле пути. Например, если путь получения равен /A, будут получены узлы A1 и A2 в узле A;
• Синхронизация: получение синхронизированных данных. Здесь используется принцип zk. Кластер zk принадлежит к окончательной согласованности. Вызвав этот метод, вы можете получить окончательное значение результата. Если вы не используете этот метод, значение, которое вы можете получить во время запроса. является промежуточным значением;

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

В основном существуют две основные концепции: Структура данных файловой системы + механизм прослушивания уведомлений.

Структура данных файловой системы

Zookeeper поддерживает структуру данных, подобную файловой системе:

Каждая запись подкаталога называется znode (узел каталога). Подобно файловой системе, мы можем свободно добавлять и удалять znodes, а также добавлять и удалять подузлы в znode. Существует шесть типов узлов:

• 1. Узел постоянного каталога НАСТОЙЧИВЫЙ., после отключения от Zookeeper,Узел все еще существует,Пока вы не удалите узел вручную,Он будет существовать вечно.
• 2. Узел каталога персистентных порядковых номеров PERSISTENT_SEQUENTIAL.,клиентиzookeeperПосле отключения,Узел все еще существует,Просто Zookeeper последовательно нумерует имя узла.
• 3. После отключения узла временного каталога EPHEMERAL от Zookeeper, узел был заменен на удаленный.
• 4. EPHEMERAL_SEQUENTIAL узел каталога временных порядковых номеров. клиентиzookeeperПосле отключения,Узел удален,Просто Zookeeper последовательно нумерует имя узла.
• 5、Container Узел (3.5.3 Версия Новинка добавлена: если под узлом «Контейнер» нет дочерних узлов, узел «Контейнер» В будущем Zookeeper будет автоматически очищать его, а запланированное задание по умолчанию будет иметь значение 60 с. Проверьте один раз).
• 6. Узел TTL (по умолчанию отключен, включить можно только через конфигурацию системы Zookeeper.extendedTypesEnabled=true, нестабильный).

Механизм прослушивания

Клиент регистрируется для прослушивания любого интересующего его узла или узлов каталога и рекурсивных узлов подкаталога:

• 1. Если вы зарегистрируетесь для мониторинга определенного узла,Затем, когда этот узел будет удален,или при изменении,Соответствующий клиент будет уведомлен.
• 2. Если вы зарегистрируетесь для мониторинга определенного каталога,Затем, когда в этом каталоге созданы дочерние узлы,Или дочерний узел удаляется,Соответствующий клиент будет уведомлен.
• 3. Если регистрация предназначена для мониторинга рекурсивных подузлов каталога, то когда любой подузел в этом каталоге имеет структуру каталогов изизменять（Дочерний узел создан,или удален) или при изменении данных корневого узла,Соответствующий клиент будет уведомлен.

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

Важные функции зоопарка

• Последовательная согласованность: соответствующие инструкции от клиента будут выполняться по порядку.,Нештатных ситуаций не будет,клиент Отправить в сервисизинструкция1->2->3->4,Эти инструкции будут выполняться по порядку;
• Атомарность: обновления имеют только успех и неудачу, без промежуточного статуса;
• Надежность: ее также можно назвать постоянством. После обновления узла его данные не изменятся до следующего обновления;
• Квази-реальное время: также называется окончательной согласованностью.,В кластере zk,Клиент модифицировал один из узлов,через определенное время,Узлы, соответствующие всем доступным сервисам, изменятся на обновленные значения.

Основные функции смотрителя зоопарка

Управление конфигурацией

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

Распределенная блокировка

Когда несколько пользователей получают доступ к данным приложения на одном хосте,Мы можем решить проблему параллельных операций, заблокировав,Но если есть несколько хостов с одним и тем же приложением, которым требуется доступ к одним и тем же данным,В настоящее время добавление блокировки на одном хосте не может решить проблему параллелизма на другом хосте.,Другими словами, ваша собственная блокировка эффективна только для вас и не влияет на других.,На этот раз вам нужна Распределенная блокировка решает такого рода проблемы, я лично понимаю Распределенную Блокировка похожа на блокировку, извлеченную со всех хостов, или существует мастер-блокировка, действительная для всех хостов. смотритель зоопарка может реализовать Распределенную Функция блокировки.

Управление кластером

В качестве центра регистрации Zookeeper управляет IP-адресом, номером порта и информацией URL-адреса поставщика услуг и отправляет их потребителю услуги, когда потребитель услуги ее запрашивает.

Классические сценарии применения Zookeeper

• распределенный Центр конфигурации
• распределенный Регистрационный центр
• Распределенная блокировка
• распределенныйочередь
• Кластерные выборы
• распределенныйбарьер
• публиковать/подписаться

Справочная статья: https://blog.csdn.net/qq_43599766/article/. подробности/125864910 https://blog.csdn.net/weixin_52851967 /статья/подробности/126241718