----- На следующий день -----
————————————
Модель данных Zookeeper
Как выглядит модель данных Zookeeper? Это очень похоже на дерево в структуре данных и на каталог в файловой системе.
Дерево состоит из узлов, и хранилище данных Zookeeper также основано на узлах.Такой тип узла называетсяZnode.
Однако, в отличие от узлов дерева, на Z-узлы ссылаютсяссылка на путь, аналогично пути к файлу:
/животные/хомяк
/Растения/Лотос
Такая иерархическая структура позволяет каждому узлу Znode иметь уникальный путь, который похож на пространство имен, чтобы четко изолировать различную информацию.
данные:
Информация о данных, хранящаяся в Znode.
Список контроля доступа:
Запишите права доступа Znode, то есть кто или какие IP могут получить доступ к этому узлу.
стат:
Содержит различные метаданные о Znode, такие как идентификатор транзакции, номер версии, метка времени, размер и т. д.
ребенок:
Ссылка на дочерний узел текущего узла, аналогичная левому дочернему правому дочернему элементу двоичного дерева.
Здесь следует отметить, что Zookeeper предназначен для сценариев с большим количеством операций чтения и меньшим количеством операций записи. Znode используется не для хранения крупномасштабных бизнес-данных, а для хранения небольшого количества информации о состоянии и конфигурации.Максимальный размер данных каждого узла не может превышать 1 МБ..
Основные операции и уведомления о событиях Zookeeper
Какие основные операции включает в себя Zookeeper? Вот список наиболее часто используемых API:
create
создать узел
delete
удалить узел
exists
Проверить, существует ли узел
getData
получить данные узла
setData
установить данные для узла
getChildren
Получить все дочерние узлы под узлом
Среди них exists, getData и getChildren являются операциями чтения. Когда клиент Zookeeper запрашивает операцию чтения, он может выбрать, устанавливать ли ееWatch.
Что означает смотреть?
Мы можем понимать это как триггер, зарегистрированный на конкретном Znode. При изменении Znode, то есть при вызове методов create, delete, setData, сработает соответствующее событие, зарегистрированное на Znode, и клиент, запрашивающий Watch, получитАсинхронное уведомление.
Конкретный процесс взаимодействия выглядит следующим образом:
1. Клиент вызывает метод getData, и параметр watch имеет значение true. Сервер получает запрос, возвращает данные узла и вставляет путь Znode для наблюдения и список наблюдателей в соответствующую хэш-таблицу.
2. Когда наблюдаемый Z-узел удален, сервер просматривает хеш-таблицу, находит всех наблюдателей, соответствующих Z-узлу, асинхронно уведомляет клиента и удаляет соответствующий ключ-значение в хэш-таблице.
Постоянство зоопарка
Как выглядит кластер Zookeeper? Как на картинке ниже:
Кластер службы Zookeeper представляет собой структуру «главный-несколько-ведомых».
При обновлении данных сначала выполните обновление на главном узле (узел здесь относится к серверу, а не к Z-узлу), а затем выполните синхронизацию с подчиненным узлом.
При чтении данных читайте любой подчиненный узел напрямую.
Чтобы обеспечить согласованность данных ведущих и подчиненных узлов, Zookeeper используетZAB-протокол, этот протокол очень похож на алгоритм консенсусаPaxosиRaft.
Прежде чем изучать ZAB, нам нужно сначала понять три состояния узла, определенные протоколом ZAB:
Looking : статус выборов.
Following : Состояние ведомого узла (подчиненного узла).
Leading : Состояние узла-лидера (главного узла).
нам еще нужно знатьМакс ZXIDКонцепция чего-либо:
Максимальный ZXID — это номер последней транзакции, локальный для узла, включаяepochи считая двумя частями. Эпоха — это значение эпохи, что эквивалентно термину, когда алгоритм Raft выбирает мастера.
Если текущий главный узел Zookeeper зависнет, кластераварийное восстановление. Восстановление после сбоя ZAB делится на три этапа:
1.Leader election
На этапе выбора узлы в кластере находятся в состоянии Looking. Каждый из них будет голосовать за другие узлы, и голосование будет содержать их собственный идентификатор сервера и идентификатор последней транзакции (ZXID).
Далее узел сравнивает свой ZXID с ZXID, полученным от других узлов, и если он обнаружит, что ZXID чужого дома больше своего, то есть данные новее своих, он повторно инициирует проголосовать и проголосовать за самый большой известный узел, которому принадлежит ZXID.
После каждого голосования сервер будет подсчитывать количество голосов, чтобы определить, получил ли узел более половины голосов. Если такой узел существует, он станет квази-лидером и его состояние изменится на «Ведущий». Статус других узлов изменится на Отслеживание.
Это эквивалентно группе мастеров боевых искусств, которые выбрали лидера боевых искусств после жесткой конкуренции.
2.Discovery
Фаза обнаружения используется для обнаружения последнего ZXID и журнала транзакций на ведомом узле. Некоторые люди могут спросить: раз лидер выбран в качестве главного узла и имеет самые последние данные в кластере, зачем нам искать последнюю транзакцию от узла?
Это делается для предотвращения некоторых непредвиденных ситуаций, таких как ситуация, когда на предыдущем этапе было создано несколько лидеров из-за сетевых причин.
Итак, на этом этапе Лидер проводит мозговой штурм и получает последние значения эпохи от всех Последователей. Лидер выбирает самую большую эпоху, добавляет 1 на основе этого значения и создает новую эпоху для распределения между каждым Последователем.
После того, как каждый ведомый получает новую эпоху, он возвращает ACK лидеру с их соответствующим наибольшим ZXID и историческим журналом транзакций. Лидер выбирает наибольший ZXID и обновляет свой собственный журнал истории.
3.Synchronization
На этапе синхронизации синхронизируйте последние исторические журналы транзакций, собранные лидером, со всеми подписчиками в кластере. Только когда половина последователей успешно синхронизирована, квазилидер может стать официальным лидером.
С этого момента восстановление после сбоя официально завершено.
чтоBroadcastШерстяная ткань? Проще говоря, когда Zookeeper регулярно обновляет данные, лидер передает их всем подписчикам. Процесс выглядит следующим образом:
1. Клиент отправляет запрос на запись данных любому ведомому устройству.
2. Последователь пересылает запрос на запись данных ведущему.
3. Лидер использует двухэтапный метод отправки и сначала отправляет широковещательную рассылку «Предложение» ведомому.
4. Последователь получает сообщение Propose и после успешной записи журнала возвращает сообщение ACK ведущему.
5. Лидер получает более половины сообщений ACK, сообщает об успехе клиенту и передает запрос на фиксацию ведомому.
Протокол Zab нельзя назвать ни сильным, ни слабым, он находится где-то посередине.Монотонная консистенция. Он использует идентификаторы транзакций и номера версий, чтобы обеспечить упорядоченность обновлений и чтения данных.
Приложение Zookeeper
1. Распределенная блокировка
Это первоначальное намерение исследователей Yahoo при разработке Zookeeper. Распределенные блокировки можно легко реализовать с помощью эфемерных последовательных узлов Zookeeper.
2. Регистрация и обнаружение службы
Используя Znode и Watcher, можно добиться регистрации и обнаружения распределенных сервисов. Наиболее известным приложением является распределенная RPC-инфраструктура Dubbo от Ali.
3. Делитесь конфигурацией и информацией о состоянии
Codis, распределенное решение Redis, использует Zookeeper для хранения таблицы маршрутизации данных и метаинформации узлов codis-proxy. При этом команды, инициированные codis-config, будут синхронизированы с каждым уцелевшим codis-proxy через ZooKeeper.
Кроме того, Kafka, HBase и Hadoop полагаются на Zookeeper для синхронизации информации об узлах для достижения высокой доступности.
Несколько дополнений:
1. Протокол ZAB относительно сложен, и Xiaohui разбирается в нем лишь поверхностно.Заинтересованные друзья могут перейти в официальное сообщество для дальнейшего изучения.
2. Этот комикс предназначен исключительно для развлечения, пожалуйста, цените свою текущую работу как можно больше и не подражайте поведению Сяо Хуэя.
Друзья, которым понравилась эта статья, нажмите и удерживайте изображение, чтобы следить за номером подписки.программист маленький серый, смотрите больше захватывающего контента