Три документа Google повлияли на многих людей и многие системы. Эти три статьи стали классикой распространения в распределенной среде. По MapReduce у нас Hadoop, по GFS — HDFS, по BigTable — HBase. И в этих трех документах один из Google Lock Service - Chubby, о, так у нас есть Zookeeper.
С популярностью больших данных люди Hxx стали знакомы, и теперь, как разработчик, если вы не знаете этих терминов, вам будет неловко здороваться с людьми, когда вы выходите на улицу. Но на самом деле для нас, разработчиков, не занимающихся большими данными, Zookeeper — это базовый сервис, который может подвергаться воздействию не только Hxx. Однако беспомощно, что он молча расположился во второй строке и никогда не был таким ослепительным, как Hxx. Так что же такое Zookeeper? Для чего можно использовать Zookeeper? Как мы будем использовать Zookeeper? Как реализован Zookeeper?
Что такое зоопарк
На официальном сайте Zookeeper есть предложение: ZooKeeper — это централизованный сервис для хранения информации о конфигурации, именования, обеспечения распределенной синхронизации и предоставления групповых услуг.
Это примерно описывает, что Zookeeper — это в основном структура координации распределенных служб, которая реализует распределенные приложения, такие как службы синхронизации, обслуживание конфигурации и службы именования. Это высокопроизводительное решение для согласованности распределенных данных.
С точки зрения непрофессионала, ZooKeeper — это смотритель зоопарка, администратор, который управляет слоном Hadoop, китом HBase, Kafka и т. д.
Отношения между Zookeeper и CAP
Для распределенной системы отказоустойчивость разделов является ключевым моментом, который необходимо учитывать. Как только распределенная система теряет отказоустойчивость разделов, это также означает отказ от масштабируемости. Поскольку в распределенной системе часто случаются сбои в сети, при возникновении такой проблемы вся система становится недоступной, что абсолютно недопустимо. Следовательно, большинство распределенных систем будут искать компромисс между согласованностью и доступностью, исходя из предпосылки обеспечения отказоустойчивости разделов.
ZooKeeper — это CP (согласованность + отказоустойчивость разделов), то есть запросы на доступ к ZooKeeper в любое время могут получить непротиворечивые результаты данных, а система отказоустойчива к сегментации сети, однако не может гарантировать доступность каждого запроса на обслуживание. То есть в экстремальных условиях ZooKeeper может отбрасывать некоторые запросы, и программе-потребителю необходимо повторно запросить для получения результатов.
ZooKeeper — это служба распределенной координации, и ее обязанностью является обеспечение синхронизации и согласованности данных между всеми службами, находящимися под ее юрисдикцией, поэтому нетрудно понять, почему ZooKeeper разработан как CP, а не AP. Более того, как основной алгоритм реализации ZooKeeper, Zab решает проблему синхронизации данных между несколькими службами в распределенной системе.
Характеристики узла Zookeeper и анализ атрибутов узла
Zookeeper обеспечивает хранение данных на основе дерева узлов каталогов, аналогичного файловой системе, но Zookeeper не используется для хранения данных конкретно, его роль в основном заключается в поддержании и отслеживании изменений состояния хранимых данных. Отслеживая изменения этих состояний данных, можно добиться управления кластером на основе данных.
модель данных
В отличие от файловой системы Linux, в файловой системе Linux есть разница между каталогами и файлами, а узел данных Zookeeper называется ZNode.ZNode — это наименьшая единица данных в Zookeeper.Каждый ZNode может сохранять данные, а также может монтировать дочерние узлы. узлов, образуя таким образом иерархическое пространство имен, называемое деревом.
Тип узла ZNode в Zookeeper можно указать при его создании, в основном это следующие типы.
ПОСТОЯННЫЙ: Постоянный узел ZNode. После создания данных, хранящихся в этой точке ZNode, они не исчезнут автоматически, если только клиент не удалит их активно.
EPHEMERAL: временный узел ZNode. Когда клиент подключается к службе Zookeeper, он устанавливает сеанс, а затем использует этот экземпляр соединения Zookeeper для создания znode этого типа. Как только клиент закроет соединение Zookeeper, сервер очистит сеанс , а затем ZNode, установленный этой сессией, исчезнет из пространства имен. Таким образом, жизненный цикл znode такого типа такой же, как и у соединения, установленного клиентом.
PERSISTENT_SEQUENTIAL: узлы ZNode, которые автоматически нумеруются последовательно.Этот тип узла znoe будет автоматически увеличиваться на 1 в соответствии с номером узла ZNode, который в настоящее время существует, и не исчезнет при отключении сеанса.
EPEMERAL_SEQUENTIAL: Временная автоматическая нумерация узлов, номер узла ZNode будет автоматически увеличиваться, но исчезнет с исчезновением Сессии
Уведомление об изменении данных наблюдателя
Zookeeper использует механизм Watcher для реализации функции публикации/подписки распределенных данных.
Механизм Watcher Zookeeper в основном состоит из трех частей: клиентского потока, клиентского WatcherManager и сервера Zookeeper. Когда клиент регистрируется на сервере Zookeeper, он сохраняет объект Watcher в клиентском WatcherManager. Когда сервер Zookeeper запускает событие Watcher, он отправляет уведомление клиенту, а клиентский поток берет соответствующий объект Watcher из WatcherManager для выполнения логики обратного вызова.
ACL обеспечивает безопасность данных
Zookeeper внутренне хранит метаданные рабочего состояния распределенной системы.Эти метаданные будут напрямую влиять на рабочее состояние распределенной системы, построенной на основе Zookeeper.Как обеспечить безопасность данных в системе, чтобы избежать данных, вызванных misoperation Исключения базы данных, вызванные случайными изменениями, очень важны.Zookeeper предоставляет полный набор механизмов контроля разрешений ACL для обеспечения безопасности данных.
Мы можем понять механизм ACL с трех аспектов: схема режима разрешений, идентификатор объекта авторизации и разрешение разрешения.Обычно «схема: идентификатор: разрешение» используется для идентификации действительной информации ACL.
данные памяти
Модель данных Zookeeper представляет собой древовидную структуру. В базе данных в оперативной памяти хранится содержимое всего дерева, включая пути всех узлов, данные узлов и информацию ACL. Zookeeper будет регулярно сохранять эти данные на диск.
DataTree: DataTree — это ядро хранилища данных в памяти, представляющее собой древовидную структуру, которая представляет полный фрагмент данных в памяти. DataTree не содержит никакой бизнес-логики, связанной с сетью, подключением клиентов и обработкой запросов, и является независимым компонентом.
DataNode: DataNode — это наименьшая единица хранения данных.Помимо сохранения содержимого данных, списка ACL и статуса узла, DataNode также записывает два атрибута: ссылку на родительский узел и список дочерних узлов.Он также предоставляет список дочерних узлов Интерфейс для работы.
ZKDatabase: база данных Zookeeper в оперативной памяти, которая управляет всеми сеансами Zookeeper, хранилищем DataTree и журналами транзакций. ZKDatabase будет периодически сбрасывать данные снимка на диск, а при запуске Zookeeper будет восстанавливать полную базу данных в памяти с помощью журнала транзакций диска и файла снимка.
Анализ принципа реализации Zookeeper
1. Структура сети Zookeeper Service
Рабочие кластеры Zookeeper можно условно разделить на две категории, один — лидер, единственный, остальные — последователи.Как определить лидера, определяется путем внутренних выборов.
Лидер и каждый ведомый общаются друг с другом, данные системы Zookeeper хранятся в памяти, а также резервируется копия на диске.
Если лидер зависнет, кластер Zookeeper будет переизбран, а лидер будет переизбран на миллисекундном уровне.
Служба Zookeeper недоступна, если не отключено более половины узлов Zookeeper в кластере.
2. Zookeeper читает и записывает данные
Для записи данных, когда клиент отправляет запрос на запись данных, если ведомый получает запрос на запись, он перенаправляет запрос ведущему, а лидер выполняет атомарную трансляцию через внутренний протокол Zab до тех пор, пока все узлы Zookeeper не будут успешно записаны. данных (синхронизация памяти и обновление диска), этот запрос на запись завершается, после чего служба Zookeeper отправляет ответ клиенту.
Чтение данных, поскольку все узлы Zookeeper в кластере представляют одно и то же представление пространства имен (то есть структурные данные), приведенный выше запрос на запись гарантирует, что однократная запись данных должна гарантировать, что все узлы Zookeeper в кластере являются синхронизированными пространствами имен, поэтому чтение может быть на любом узле Zookeeper.
3. Как работает Zookeeper
Заб протокол
Ядром Zookeeper является широковещательная рассылка, обеспечивающая синхронизацию между серверами. Протокол, реализующий этот механизм, называется протоколом Zab.
Протокол атомарной рассылки сообщений Zab (ZooKeeper Atomic Broadcast) является основным алгоритмом обеспечения согласованности данных.Протокол Zab представляет собой алгоритм широковещательной рассылки атомарных сообщений для восстановления после сбоя, специально разработанный для Zookeeper.
Ядро протокола Zab выглядит следующим образом:
Все запросы транзакций должны координироваться глобально уникальным сервером (лидером), а остальные серверы в кластере называются серверами-последователями. Ведущий сервер отвечает за преобразование клиентского запроса в предложение транзакции и распространение предложения на все подчиненные серверы в кластере. После этого сервер-лидер должен дождаться отзывов от всех серверов-последователей.Как только более половины серверов-последователей дадут правильный отзыв, сервер-лидер снова разошлет сообщение фиксации всем серверам-последователям, попросив их отправить предыдущее предложение. .
Заб режим
Протокол Zab включает два основных режима: восстановление после сбоя и широковещательная рассылка сообщений.
Когда запускается вся сервисная структура или на ведущем сервере возникают сетевые прерывания, сбои, выходы и перезапуски, протокол Zab переходит в режим восстановления и выбирает новый ведущий сервер.
Когда выбран новый сервер-лидер и более половины машин в кластере завершили синхронизацию состояния с сервером-лидером, протокол Zab выйдет из режима восстановления.Синхронизация состояния относится к синхронизации данных, которая используется для обеспечения того, чтобы кластер находится более чем в половине машин и может согласовываться с состоянием данных сервера Лидер.
Когда более половины подчиненных серверов в кластере завершили синхронизацию состояния с ведущим сервером, вся сервисная структура может перейти в режим широковещательной рассылки сообщений.
При запуске и добавлении в кластер сервера, также соответствующего протоколу Zab, если в кластере уже есть сервер-лидер, отвечающий за рассылку сообщений, присоединяемый сервер осознанно перейдет в режим восстановления данных: найти сервер, на котором находится лидер находится , и синхронизировать с ним данные, а затем вместе участвовать в процессе рассылки сообщений.
Zookeeper разрешает обрабатывать запросы транзакции только одному серверу-лидеру.После того, как сервер-лидер получит запрос на транзакцию клиента, он сгенерирует соответствующее предложение транзакции и инициирует раунд широковещательного протокола, и если другие машины в кластере получат запрос на транзакцию клиента. запрос на транзакцию, эти серверы, не являющиеся лидерами, сначала перенаправят запрос на транзакцию на сервер-лидер.
широковещательное сообщение
Процесс широковещательной рассылки сообщений протокола Zab использует протокол атомарной широковещательной рассылки, аналогичный процессу отправки 2PC. конкретный:
ZooKeeper использует один основной процесс Leader для обработки всех запросов клиентов на транзакции и протокол атомарной широковещательной рассылки Zab для передачи изменений состояния данных сервера подписчикам в виде предложений транзакций, поэтому он может обрабатывать большое количество одновременных запросов от клиентов.
С другой стороны, поскольку между транзакциями могут быть зависимости, протокол Zab гарантирует, что последовательность изменений, транслируемых Лидером, обрабатывается последовательно, и некоторые изменения состояния должны зависеть от тех изменений состояния, которые были сгенерированы раньше него.
Наконец, учитывая, что лидер основного процесса может аварийно завершить работу в любой момент, протокол Zab также должен повторно выбрать лидера при сбое процесса-лидера и обеспечить целостность данных; после того, как Подчиненный получит Предложение, он записывает на диск и возвращает Ack. После того, как лидер получит большую часть ACK, он рассылает сообщение Commit и фиксирует само сообщение. После того, как Подписчик получает фиксацию, он отправляет сообщение.
Протокол Zab упрощает отправку транзакций 2PC:
Уберите удаление логики прерывания, последователь либо подтверждает, либо отказывается от лидера.
Лидеру не нужны все Последователи для успешного ответа, пока достаточно большинства Подтверждений.
аварийное восстановление
Выше мы говорили о процессе рассылки сообщений протокола Zab в обычных условиях, после чего, как только ведущий сервер выйдет из строя или потеряет связь более чем с половиной серверов-последователей, он перейдет в режим восстановления после сбоя.
В режиме восстановления необходимо переизбрать нового лидера, чтобы восстановить все серверы в правильное состояние.
Практика зоопарка, общие замки, выборы лидера
Распределенные блокировки используются для управления способом синхронного доступа к общим ресурсам между распределенными системами, что может обеспечить согласованность при доступе разных систем к одному или группе ресурсов.Они в основном делятся на эксклюзивные блокировки и общие блокировки.
Эксклюзивные блокировки также известны как блокировки записи или эксклюзивные блокировки.Если транзакция T1 добавляет монопольную блокировку к объекту данных O1, то только транзакция T1 может читать и обновлять объект O1 в течение всего периода блокировки, а любая другая транзакция разрешена. над этим объектом данных можно выполнять любые операции, пока T1 не снимет монопольную блокировку.
Общие блокировки также называются блокировками чтения.Если транзакция T1 добавляет общую блокировку к объекту данных O1, то текущая транзакция может выполнять только операции чтения для O1, а другие транзакции могут только добавлять общие блокировки к этому объекту данных, пока объект данных не будет заблокирован , Все общие блокировки сняты.
Выборы лидера
Выбор лидера является ключом к обеспечению согласованности распределенных данных. Когда сервер в кластере Zookeeper имеет одно из следующих двух условий, ему необходимо участвовать в выборах лидера.
Сервер изначально запущен.
Соединение с Лидером не может поддерживаться во время работы сервера.
Zookeeper сохраняет только TCP-версию алгоритма выборов FastLeaderElection после версии 3.4.0. Когда машина входит в выборы лидера, текущий кластер может находиться в следующих двух состояниях:
Лидер уже существует в кластере.
Лидер не существует в кластере.
Для лидера, который уже есть в кластере, такая ситуация обычно означает, что машина запускается с опозданием, до его запуска кластер уже нормально работает, в этом случае при попытке выбрать лидера машина будет уведомлена Лидер информация о текущем сервере, для этой машины нужно только установить соединение с машиной-лидером и синхронизировать статус.
В случае отсутствия лидера в кластере это будет относительно сложно, шаги следующие:
(1) ПЕРВОЕ ГОЛОСОВАНИЕ. Независимо от того, какая из них приводит к выборам лидера, все машины в кластере находятся в состоянии попытки выбрать лидера, то есть в состоянии LOOKING, и машина LOOKING отправит сообщение всем остальным машинам, которое называется голосование. Голосование содержит SID (уникальный идентификатор сервера) и ZXID (идентификатор транзакции).Форма (SID, ZXID) используется для идентификации информации о голосовании. Предположим, что Zookeeper состоит из 5 машин, SID — 1, 2, 3, 4 и 5, а ZXID — 9, 9, 9, 8 и 8 соответственно, а машина с SID 2 — это машина-лидер. В какой-то момент машина, на которой расположены 1 и 2, выходит из строя, поэтому кластер начинает проводить выборы лидера. При голосовании в первый раз каждая машина будет использовать себя в качестве объекта голосования, поэтому ситуации голосования машин с SID 3, 4 и 5 будут (3, 9), (4, 8), (5, 8).
(2) Изменить голос. После того, как каждая машина отправит голос, она также получит голоса от других машин.Каждая машина будет обрабатывать голоса, полученные другими машинами, в соответствии с определенными правилами, и использовать это, чтобы решить, следует ли изменить свой собственный голос.Это правило также является всем Лидером В основе алгоритма выборов лежит описанная ниже терминология.
voice_sid: SID рекомендуемого сервера-лидера в полученном голосовании.
voice_zxid: ZXID рекомендованного сервера-лидера в полученном голосовании.
self_sid: собственный SID текущего сервера.
self_zxid: собственный ZXID текущего сервера.
Каждый раз, когда обрабатывается полученный голос, это процесс сравнения (vote_sid, voice_zxid) и (self_sid, self_zxid).
Правило 1: Если voice_zxid больше, чем self_zxid, текущий полученный голос распознается, и голос отправляется снова.
Правило 2: Если voice_zxid меньше, чем self_zxid, придерживайтесь своего голоса, не внося никаких изменений.
Правило 3: Если voice_zxid равен self_zxid, тогда сравните их SID.Если voice_sid больше, чем self_sid, то распознается текущий полученный голос, и голос отправляется снова.
Правило 4: Если voice_zxid равен self_zxid, а voice_sid меньше self_sid, то придерживайтесь своего голоса, не внося никаких изменений.
В сочетании с приведенными выше правилами дается следующий процесс изменения кластера.
(3) Определите лидера. После второго тура голосования каждая машина в кластере снова получит голоса от других машин, а затем начнет подсчет голосов.Если машина наберет больше половины таких же голосов, то SID-машина, соответствующая этому голосованию, становится лидером. В этот момент Server3 станет лидером.
Как видно из приведенных выше правил, обычно чем новее данные на этом сервере (чем больше будет ZXID), тем больше у него шансов стать лидером и тем более гарантировано восстановление данных. Если ZXID одинаковый, чем больше SID, тем больше вероятность.