Сначала лайк, потом смотри, формируй привычку 🌹
Добро пожаловать в WeChat: путь программирования на Java
Делайте небольшие успехи каждый день, накапливайте технологии и делитесь знаниями.
ZAB-протокол
Это конец восьмидневного веселья в честь Национального дня! Праздников в 2020 году больше не будет! Тебе плохо, одноклассник?
Сегодня давайте кратко поговорим о протоколе ZAB, Лично я считаю, что понимание взаимосвязи и процесса протокола ZAB и алгоритма выбора лидера является незаменимым звеном для глубокого понимания Zookeeper.
Пожалуйста, позвольте мне с нетерпением ждать нового года
Zookeeper
Энциклопедия Baidu: ZooKeeper — это распределенная служба координации распределенных приложений с открытым исходным кодом, реализация с открытым исходным кодом Chubby от Google и важный компонент Hadoop и Hbase.
Это программное обеспечение, которое предоставляет согласованные услуги для распределенных приложений.Предоставляемые функции включают в себя: обслуживание конфигурации, службу доменных имен, распределенную синхронизацию, групповую службу и т. д.
Zookeeper — очень популярный распределенный фреймворк, важно освоить базовое использование ZK, реализацию распределенных блокировок и использование связанных сценариев. мне повезло бытьShopeeВ интервью меня спросили о протоколе ZAB и избирательном процессе Лирдера, поэтому я подведу итог и поделюсь с вами своим пониманием, надеюсь, оно вам поможет.
Сегодня я не буду знакомить с основами использования ZK, а лишь поделюсь пониманием протокола ZAB в ZK.Если есть какие-то недостатки, прошу указать.
ZAB-протокол
Полное название протокола ZAB: Zookeeper Atomic Broadcast (протокол атомной трансляции Zookeeper).
Zookeeper — это эффективная и надежная распределенная служба координации для распределенных приложений. В теории CAP Zookeeper принадлежит к модели CP, которая подчеркивает строгую согласованность данных между узлами и устанавливает высокодоступную и масштабируемую распределенную основную и резервную систему данных через протокол zab.
- Только глубоко поняв протокол ZAB, мы сможем лучше понять важность zookeeper для построения распределенных систем. И почему использование zookeeper может обеспечить возможную согласованность данных в распределенных системах и высокую доступность сервисов.
Принцип протокола ZAB
Протокол ZAB требует, чтобы каждый лидер прошел три этапа, а именно обнаружение, синхронизацию и трансляцию.
- Обнаружить: то есть кластер zookeeper должен выбрать процесс-лидер, и лидер будет поддерживать доступный список последователей. В будущем клиенты смогут взаимодействовать с узлами этого повторителя.
- Синхронизировать: Лидер отвечает за синхронизацию своих данных с ведомыми для обеспечения многокопийного хранилища. Это также отражает высокую доступность и отказоустойчивость разделов в CAP. После того, как фолловер использует необработанные запросы в очереди, он записывает их в локальный журнал транзакций.
- транслировать: Лидер может принять новый запрос предложения клиента и передать новый запрос предложения всем подписчикам.
Заявление
- Atomic Broadcast (когда доступен Лидер)
- Аварийное восстановление (когда Лидер недоступен)
Ниже я остановлюсь на этих двух вещах.
Zookeeper устанавливает модель «активный-резервный» в соответствии с протоколом ZAB для синхронизации данных в кластере zookeeper. Упомянутая здесь первичная и вторичная модели системной архитектуры означают, что в кластере zookeeper только一台leaderОтвечает за работу с внешними клиентами事务请求(или операций записи), то ведущий сервер отправляет клиенту写操作数据синхронизировать с所有的followeр узел.
Уведомление:
- Все операции выдает Лидер, а мгновенный клиент отправляет запрос Цветку, который в итоге передает запрос Лидеру на обработку.
Как реплицируются данные?
По сути, репликация данных по протоколу zab аналогична 2PC. Но ZAB нужен только Follower, чтобы иметь一半以上返回Ackинформация может быть выполненаcommitОтправить. Метод отправки после получения половины подтверждения может значительно уменьшить блокировку синхронизации и избежать слишком долгого ожидания обратной связи от всех узлов перед выполнением операций (либо все успешно, либо все неудачно).
То, как вы поймете это предложение, напрямую повлияет на ваше понимание ZAB. Поэтому, пожалуйста, продолжайте читать!
диаграмма
- В zk-кластере всего одна нода, то есть лидер, который записывает операцию записи клиента.
转化为事务(или предложение-предложение) -- Запомните смысл этого предложения и он пробежит всю систему зк. - После того, как ведущий узел закончит запись данных, он отправит широковещательный запрос данных (копирование) всем узлам-последователям, ожидая, когда все узлы-последователи
反馈（Ack). - Когда лидер получает более половины обратной связи узла-последователя (Ack), узел-лидер отправит все серверы-последователи.
发送commit（事务提交）Информация. - Наконец, данные синхронизируются с повторителем для завершения синхронизации данных.
широковещательное сообщение
В кластере Zookeeper связь между Цветком и Лидером осуществляется через очередь сообщений Добавление очереди сообщений уменьшает связанность и освобождает блокировку синхронизации.
Конкретные шаги трансляции сообщений в Zookeeper следующие::
- Клиент инициирует запрос операции записи, а ведущий сервер преобразует запрос клиента в предложение транзакции и назначает предложение каждому предложению.
全局递增唯一, то есть ZXID (идентификатор транзакции). - Между сервером-лидером и каждым фолловером, которому лидер отправляет сообщения, существует очередь.
- Машина-последователь берет сообщение из очереди и обрабатывает его (
写入本地事物日志中), отправьте подтверждение ACK на ведущий сервер. - После того как ведущий сервер получает ACK от более чем половины фолловеров, он считает, что фиксация может быть отправлена. Лидер отправляет сообщения фиксации всем серверам-последователям.
аварийное восстановление
В процессе рассылки сообщения, о котором мы только что говорили, лидер внезапно падает и отключается в определенный момент времени, как мы можем обеспечить непротиворечивость данных, например, лидер отправляет локально, но коммит не отправляется?
Протокол Zab требует, чтобы кластер zookeeper продолжал работу сразу после сбоя исходного лидера.崩溃恢复а такжеleader选举. Кратко поговорим о механизме аварийного восстановления.
Требования к восстановлению после сбоя протокола ZAB соответствуют следующим двум принципам:
- Убедитесь, что предложение было подано руководителем
必须最终Отправляется всеми серверами-последователями. - убедись
丢弃Предложение, которое было сделано лидером, но не было представлено.
Поэтому ZAB разработал алгоритм выборов:
Раньше каждый клиентский запрос, который мы отправляли клиенту, был заключен лидером в идентификатор транзакции с уникальным приращением, если мы можем гарантировать, что вновь избранный лидерный узел содержит наивысший ZXID. Тогда могут быть соблюдены два важных принципа протокола ZAB. Сюда可以省去 Leader 服务器检查事务的提交和丢弃工作的这一步操作
Почему?
Перед сбоем Лидера идентификаторы транзакций всех Цветов, которые берут транзакцию из очереди на обработку, должны совпадать. Если мы сможем выбрать сервер с наибольшим ZXID из существующих цветов:
- Предположим: лидер вылетает перед отправкой предложения, тогда сервер, на котором найден самый большой ZXID, не должен содержать неотправленное предложение.
- Предположение: ведущий аварийно завершает работу после отправки сообщения фиксации. То есть сообщение было отправлено в очередь, и предложение, которое должно быть отправлено, будет обработано Цветком, тогда мы должны найти сервер с наибольшим ZXID. То есть узел-последователь будет выбран последним лидером.
Что необходимо сделать после избрания лидера, так это синхронизацию данных между лидером и цветами.
синхронизация данных
О синхронизации данных В Zookeeper существует четыре типа синхронизации данных:
- DIFF: прямая дифференциальная синхронизация
- TRUNC+DIFF: сначала откат, а затем дифференциальная синхронизация
- TRUNC: только синхронизация отката
- SNAP: полная синхронизация
На этот раз я не буду вдаваться в подробности о четырех методах. Вы можете обратиться к "Zookeeper - синхронизация данных«В этой статье я просто кратко представляю концепцию синхронизации данных ZK.
После успешного выбора нового лидера в кластере Zookeeper лидер отправит транзакцию ZXID собственного максимального предложения (proposal) другим узлам-последователям. Узел-последователь будет действовать в соответствии с сообщением лидера.回退или数据同步работать. Чтобы узнать о конкретном процессе, перейдите в раздел «Синхронизация данных Zookeeper».
Как кластер Zookeeper обеспечивает глобальную уникальность ZXID, назначенного вновь избранным лидером?
ZXID — это число длиной 64 бита, из которых младшие 32 бита数字递增, то есть каждый раз, когда клиент инициирует предложение, младшее 32-битное число просто увеличивается на 1. Старшие 32 бита являются ведущим циклом.epoch编号, всякий раз, когда избирается новый лидер, новый лидер本地事物日志中取出ZXID, а затем проанализируйте старший 32-битный номер эпохи,进行加1, а затем младшие 32-разрядные全部设置为0. Это гарантирует, что после каждого вновь избранного лидера уникальность ZXID гарантирована и保证递增из.
Суммировать
Внедрение протокола ZAB — это пока слишком много. Zookeeper использует протокол ZAB для обеспечения строгой согласованности кластера Zookeeper.类2PC的数据复制метод иZXID的唯一性设计.
Что касается Zookeeper, то будет еще одно знакомство с принципом реализации распределенных блокировок Zookeeper и алгоритмом выбора лидера.Это высокочастотные тестовые площадки в интервью Zookeeper.Заинтересованные студенты могут обратить внимание на мой официальный аккаунт.«Путь программирования на Java»Ой!