28 вопросов для интервью ZooKeeper, которые больше всего задавали интервьюеры в 2019 году

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

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

1. Вопросы для собеседования с ZooKeeper?

2. Что предоставляет ZooKeeper?

3. Файловая система Zookeeper

4. Протокол ZAB?

5. Четыре типа узлов данных Znode

6. Механизм Zookeeper Watcher -- уведомление об изменении данных

7. Клиент регистрирует реализацию Watcher

8. Реализация Watcher для серверной обработки

9. Наблюдатель обратного вызова клиента

10. Механизм контроля разрешений ACL

11. Функции Chroot

12. Управление сессиями

13. Роли сервера

14. Рабочий статус сервера под Zookeeper

15. Синхронизация данных

16. Как zookeeper обеспечивает последовательную согласованность транзакций?

17. Зачем в распределенном кластере Мастер?

18. Как бороться с простоями zk node?

19. Разница между балансировкой нагрузки zookeeper и балансировкой нагрузки nginx

20. Zookeeper, у которого есть несколько моделей развертывания?

21. Какое минимальное количество машин, необходимых для кластера? Каковы правила кластера?

22. Поддерживает ли кластер динамическое добавление машин?

23. Являются ли уведомления мониторинга Zookeeper для узлов постоянными? Почему не постоянный?

24. Что такое Java-клиенты Zookeeper?

25. Что такое чубби и чем он отличается от смотрителя зоопарка?

26. Произнесите несколько общих команд смотрителя зоопарка.

27. Связь и различие алгоритмов ZAB и PAXOS?

28. Типичные сценарии применения Zookeeper

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

Распределенные приложения могут реализовывать такие функции, как публикация/подписка на данные, балансировка нагрузки, службы именования, распределенная координация/уведомление, управление кластером, выбор мастера, распределенные блокировки и распределенные очереди на основе Zookeeper.

Zookeeper гарантирует следующие характеристики распределенной согласованности:

(1) Последовательная согласованность

(2) атомарность

(3) Один вид

(4) Надежность

(5) В режиме реального времени (возможная согласованность)

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

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

(1) Файловая система

(2) Механизм уведомления

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

Чтобы обеспечить высокую пропускную способность и низкую задержку, Zookeeper поддерживает эту древовидную структуру каталогов в памяти, что делает Zookeeper неспособным хранить большой объем данных, а верхний предел хранения данных для каждого узла составляет 1 МБ.

Протокол ZAB — это атомарный широковещательный протокол, специально разработанный для службы распределенной координации Zookeeper для поддержки восстановления после сбоев.

Протокол ZAB включает два основных режима: восстановление после сбоя и широковещательная рассылка сообщений.

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

(1) PERSISTENT-постоянный узел

Узлы существуют в Zookeeper, если только они не удалены вручную

(2) EPHEMERAL-временный узел

Жизненный цикл временной ноды привязан к клиентской сессии.Если клиентская сессия недействительна (клиент отключен от zookeeper, сессия не может быть недействительной), то все временные ноды, созданные клиентом, будут удалены.

(3) PERSISTENT_SEQUENTIAL — постоянный узел последовательности

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

(4) EPHEMERAL_SEQUENTIAL-узел временной последовательности

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

Zookeeper позволяет клиенту зарегистрировать прослушиватель Watcher с Znode на сервере.Когда некоторые указанные события на сервере запускают этот Watcher, сервер отправит уведомление о событии указанному клиенту для реализации функции распределенного уведомления, а затем клиент Следите за Наблюдателем. Уведомляйте о состояниях и типах событий, чтобы вносить изменения в бизнес.

Рабочий механизм:

(1) Клиент регистрирует наблюдателя

(2) Наблюдатель за серверной обработкой

(3) Наблюдатель обратного вызова клиента

Сводка наблюдения функций:

(1) Одноразовый

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

(2) Последовательное выполнение клиента

Процесс обратного вызова клиентского Watcher представляет собой процесс последовательной синхронизации.

(3) Легкий

3.1 Уведомление Watcher очень простое, оно только сообщает клиенту, что произошло событие, и не объясняет конкретное содержание события.

3.2 Когда клиент регистрирует Watcher на сервере, он не передает реальную объектную сущность Watcher клиента серверу, а только использует атрибут логического типа, чтобы пометить его в клиентском запросе.

（4）watcher event 异步发送 watcher 的通知事件从 server 发送到 client 是异步的，这就存在一个问题，不同的客户端和服务器之间通过 socket 进行通信，由于网络延迟或其他因素导致客户端在不通的时刻监听到事件，由于 Zookeeper 本身提供了 ordering guarantee，即客户端监听事件后，才会感知它所监视 znode发生了变化。 Поэтому мы не можем ожидать, что сможем отслеживать каждое изменение узла с помощью Zookeeper. Zookeeper может гарантировать только конечную согласованность, а не сильную согласованность.

(5) Зарегистрируйте наблюдатель getData, exists, getChildren

(6) Триггерный наблюдатель создает, удаляет, устанавливает данные

(7) Когда клиент подключается к новому серверу, часы будут запущены любым событием сеанса. Когда соединение с сервером потеряно, часы не могут быть получены. И когда клиент повторно подключается, все ранее зарегистрированные часы будут зарегистрированы повторно, если это необходимо. Обычно это совершенно прозрачно. Существует только один особый случай, когда наблюдение может быть потеряно: существующее наблюдение за несозданным znode, если оно было создано во время отключения клиента и впоследствии удалено до подключения клиента, в этом случае событие наблюдения может быть потеряно.

(1) Вызвать три API getData()/getChildren()/exist() и передать объект Watcher

(2) Отметьте запрос запроса и инкапсулируйте Watcher в WatchRegistration.

(3) Инкапсулировать его в объект Packet и отправить серверу для отправки запроса

(4) После получения ответа от сервера зарегистрируйте Watcher в ZKWatcherManager для управления

(5) Запрос возвращается для завершения регистрации.

(1) Сервер получает Watcher и сохраняет его

Получите запрос клиента, обработайте запрос, чтобы определить, следует ли регистрировать Наблюдателя, и, если необходимо, подключите путь узла данных к ServerCnxn (ServerCnxn представляет собой соединение между клиентом и сервером и реализует интерфейс процесса Наблюдателя). , который в настоящее время можно рассматривать как объект Watcher. ) хранятся в WatchTable и watch2Paths WatcherManager.

(2) Триггер наблюдателя

В качестве примера возьмем сервер, получающий запрос транзакции setData() для запуска события NodeDataChanged:

2.1 Инкапсуляция WatchedEvent

Инкапсулировать статус уведомления (SyncConnected), тип события (NodeDataChanged) и путь узла в объект WatchedEvent.

2.2 Наблюдатель запросов

Найти Watcher на основе пути к узлу из WatchTable

2.3 Не найдено означает, что ни один клиент не зарегистрировал Watcher на узле данных

2.4 Найдите, извлеките и удалите соответствующий Watcher из WatchTable и Watch2Paths (из этого видно, что Watcher одноразовый на стороне сервера, и при однократном срабатывании он будет невалидным)

(3) Вызовите метод процесса, чтобы вызвать Watcher

Процесс здесь в основном заключается в отправке уведомлений о событиях Watcher через TCP-соединение, соответствующее ServerCnxn.

Клиентский поток SendThread получает уведомление о событии и передает его потоку EventThread для обратного вызова Наблюдателя.

Механизм Watcher клиента также является одноразовым, после срабатывания Watcher становится недействительным.

UGO (Пользователь/Группа/Другие)

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

ACL (список управления доступом) список управления доступом

Он включает в себя три аспекта:

Режим разрешения (схема)

(1) IP: управление доступом на основе детализации IP-адресов

(2) Дайджест: наиболее часто используемая конфигурация разрешений, аналогичная имени пользователя: пароль, используется для конфигурации разрешений, что позволяет легко различать разные приложения для управления разрешениями.

(3) Мир: самый открытый метод управления разрешениями — это специальный режим дайджеста, в котором используется только один идентификатор разрешения «мир: любой».

(4) Супер: Суперпользователь

Авторизованный объект

Авторизованный объект относится к пользователю или указанному объекту, которому предоставлены полномочия, такие как IP-адрес или машинный свет.

Разрешение

(1) CREATE: разрешение на создание узла данных, позволяющее авторизованным объектам создавать дочерние узлы в Znode.

(2) DELETE: разрешение на удаление дочернего узла, позволяющее авторизованному объекту удалять дочерние узлы узла данных.

(3) ЧТЕНИЕ: разрешение на чтение узла данных, позволяющее авторизованным объектам получать доступ к узлу данных и читать его содержимое данных или список дочерних узлов и т. д.

(4) WRITE: полномочия обновления узла данных, позволяющие авторизованным объектам обновлять узел данных.

(5) ADMIN: полномочия управления узлом данных, позволяющие авторизованным объектам выполнять операции настройки, связанные с ACL, на узле данных.

После версии 3.2.0 была добавлена ​​функция Chroot, позволяющая каждому клиенту устанавливать для себя пространство имен. Если клиент находится в chroot, любые операции, которые клиент может выполнять с сервером, будут ограничены его собственным пространством имен.

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

Стратегия обмена ковшами: управлять аналогичными сеансами в том же блоке, чтобы зоофидер мог изолировать различные блоки для сеансов и равномерно обрабатывать один и тот же блок.

Принцип распределения: «следующий тайм-аут» (ExpirationTime) каждой сессии.

Формула расчета:

ExpirationTime_ = currentTime + sessionTimeout

ExpirationTime = (ExpirationTime_ / ExpirationInrerval + 1) *

ExpirationInterval , ExpirationInterval — это интервал проверки тайм-аута сеанса Zookeeper, по умолчанию tickTime

Leader

(1) Единственный планировщик и обработчик запросов транзакций для обеспечения упорядоченности обработки транзакций кластера

(2) Планировщик каждой службы в кластере

Follower

(1) Процесс нетразакировать запрос клиента и пересылать транзакционный запрос на сервер лидера

(2) Участвовать в голосовании предложений по запросам на сделки

(3) Участвовать в голосовании на выборах лидера

Observer

(1) Роль сервера, представленная после версии 3.0, улучшает возможности кластера по обработке транзакций, не влияя на возможности обработки транзакций кластера.

(2) Обработать нетранзакционный запрос клиента и перенаправить транзакционный запрос на ведущий сервер.

(3) Не участвовать в голосовании ни в какой форме.

У сервера есть четыре состояния: СМОТРЮ, СЛЕДУЮЩИЙ, ВЕДУЩИЙ, НАБЛЮДАЮЩИЙ.

(1) ИЩУ: Найдите статус лидера. Когда сервер находится в этом состоянии, он будет думать, что в текущем кластере нет лидера, поэтому ему необходимо войти в состояние выбора лидера.

(2) FOLLOWING: Статус ведомого. Указывает, что текущая роль сервера — Follower.

(3) LEADING: Статус лидера. Указывает, что текущая роль сервера — Лидер.

(4) НАБЛЮДЕНИЕ: состояние наблюдателя. Указывает, что текущая роль сервера — Наблюдатель.

После того, как весь кластер завершает выборы Лидера, Ученик (в совокупности именуемый Последователем и Наблюдателем) регистрируется на сервере Лидера. Когда сервер Learner завершает регистрацию на сервере Leader, он вводит ссылку для синхронизации данных.

Процесс синхронизации данных: (все в виде передачи сообщений)

Учащийся Зарегистрируйтесь в Ученике

синхронизация данных

подтверждение синхронизации

Синхронизация данных Zookeeper обычно делится на четыре категории:

(1) Прямая дифференциальная синхронизация (DIFF-синхронизация)

(2) Сначала откат, а затем дифференцированная синхронизация (синхронизация TRUNC+DIFF)

(3) Только синхронизация отката (синхронизация TRUNC)

(4) Полная синхронизация (синхронизация SNAP)

Перед синхронизацией данных сервер Лидер завершит инициализацию синхронизации данных:

сверстникLastZxid:

· Извлечение сообщений, отправленных с регистрации ACKEPOCH сервера учащегося lastZxid (сервер учащегося последний раз обрабатывал ZXID)

МинКоммитлоглог:

Минимальный ZXIDmaxCommittedLog в очереди кэша предложений на сервере-лидере commitLog:

· Самый большой ZXID в очереди кэша предложений на ведущем сервере commitLog — это прямая дифференцированная синхронизация (синхронизация DIFF)

Сценарий: peerLastZxid находится между minCommittedLog и maxCommittedLog, сначала выполняется откат, а затем дифференцированная синхронизация (синхронизация TRUNC+DIFF).

· Сценарий: когда новый ведущий сервер обнаруживает, что обучающий сервер содержит запись о транзакции, которой у него нет, ему необходимо позволить обучающему серверу откатить транзакцию до той, которая существует на ведущем сервере, и также ближе всего к peerLastZxid ZXID только для отката синхронизации (синхронизация TRUNC)

· Сценарий: Peerlastzxid больше, чем maxCommemitedLog

Полная синхронизация (синхронизация SNAP)

Сценарий 1: peerLastZxid меньше, чем minCommittedLog

Сценарий 2: На сервере Leader нет очереди кэша предложений, а peerLastZxid не равен lastProcessZxid.

zookeeper использует глобальный инкрементный идентификатор транзакции для идентификации, все предложения (предложения) добавляются с zxid, когда они предлагаются, zxid на самом деле является 64-битным числом, а верхние 32 бита — это эпоха (период; эпоха; мир; новая эра). используется для идентификации цикла лидера.Если генерируется новый лидер, эпоха будет автоматически увеличиваться, а младшие 32 бита используются для увеличения счетчика. Когда создается новое предложение, оно сначала отправляет запрос на выполнение транзакции другим серверам в соответствии с двухэтапным процессом базы данных.Если более половины машин могут выполнить и выполнить успешно, тогда выполнение начнется.

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

Сам Zookeeper тоже является кластером, и рекомендуется настраивать не менее 3-х серверов. Сам Zookeeper также гарантирует, что, когда узел выйдет из строя, другие узлы продолжат предоставлять услуги.

Если подписчик выходит из строя, остается 2 сервера для предоставления доступа, потому что данные на Zookeeper имеют несколько копий, и данные не будут потеряны;

Если лидер выйдет из строя, Zookeeper выберет нового лидера.

Механизм кластера ZK заключается в том, что пока более половины узлов работают нормально, кластер может нормально предоставлять услуги. Кластер выходит из строя только тогда, когда висит слишком много узлов ZK и работает только половина или меньше узлов.

так

Кластер из 3 узлов может вывести из строя 1 узел (лидер может получить 2 голоса > 1,5)

Кластер из 2 узлов не может повесить ни один узел (лидер может получить 1 голос

Данные публиковать/подписываться

балансировки нагрузки

Приглашаю всех обратить внимание на мой официальный аккаунт [Программист в погоне за ветром].В 2019 году многие компании собрали более 1000 400-страничных pdf-документов для вопросов на собеседовании по java.