Введение

Всем привет, я вашБум брат, Небо не боится, земля не боится, Боюсь, что ты не войдешь.

В этой статье описан процесс обучения ZK, ZK действительно очень мощное промежуточное ПО, оно разработано JAVA,многоуровневая очередьДизайн просто невероятный,Изучите идею исходного кода. Но я все еще должен пожаловаться, именование в исходном коде ZK верно.... Я не буду этого говорить.По сравнению с исходным кодом Spring, это действительно намного сложнее.

2. Введение в ЗК

Прежде чем понять Zookeeper, вам необходимо иметь определенное представление о распределенных связанных знаниях, так что же такое распределенная система?

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

Что такое зоозащитник?

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

Основные концепции Zookeeper

структура данных файловой системы+Механизм уведомления монитора.

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

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

Каждая запись подкаталога называетсяZnode (узел каталога), Подобно файловой системе, мы можем свободно добавлять и удалять znode, а также добавлять и удалять дочерние znode под znode.

Существует четыре типа znodes:

1,ПОСТОЯННЫЙ постоянный узел: после отключения клиента узла каталога от zookeeper узел все еще существует, пока узел не будет удален вручную, он будет существовать вечно.

2,PERSISTENT_SEQUENTIAL постоянный узел последовательности: После отключения клиента от zookeeper узел все еще существует, но Zookeeper последовательно нумерует имя узла.

3.EPHEMERAL временный узел: после отключения клиента от zookeeper узел удаляется. иВременные узлы не могут создавать дочерние узлы.

4.Узел временной последовательности EPHEMERAL_SEQUENTIAL: после отключения клиента от zookeeper узел удаляется, но Zookeeper последовательно нумерует имя узла.

5.Контейнерный узел(Новое в версии 3.5.3: если под узлом-контейнером нет дочернего узла, в будущем узел-контейнер будет автоматически очищаться Zookeeper, а запланированное задание будет проверяться каждые 60 секунд по умолчанию).

6.узел ТТЛ(Отключено по умолчанию, может быть включено только системной конфигурацией zookeeper.extendedTypesEnabled=true, нестабильно).

2. Механизм уведомления о мониторинге

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

1. Если регистрация заключается в мониторе узла, когда узел удален или изменен, соответствующий клиент будет уведомлен

2. Если регистрация предназначена для мониторинга каталога, соответствующий клиент будет уведомлен при создании дочернего узла этого каталога или удалении дочернего узла.

3. Если регистрация предназначена для мониторинга рекурсивных дочерних узлов каталога, когда любой дочерний узел в каталоге имеет изменение в структуре каталога (дочерние узлы создаются или удаляются) или корневой узел имеет изменения данных, соответствующие клиенты будут уведомлены. .

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

Сценарии применения Zookeeper

Об идее

• Распределенная очередь: Это может быть достигнуто с помощью постоянных последовательных узлов ZK.

• Кластерные выборы: Это может быть реализовано через функцию выбора лидера ZK.

• опубликовать подписаться: То есть функция контроля регистрации ЗК.

• Центр распределенной конфигурации,Регистрационный центр

  1. Создайте ПОСТОЯННЫЙ постоянный узел,create /config/项目名 配置文件的JSON格式
  2. Клиент слушает этот узел,get -w /config/项目名, когда данные узла меняются, это означает, что файл конфигурации JSON изменился, и клиент может воспринять это впервые. Так как мониторинг является одноразовым, можно выполнять мониторинг контура.

• Распределенная блокировка(выделение добавлено здесь)

  Распределенные замки ZK можно разделить начестный замокинесправедливый замок

  несправедливый замок:

  1. Приходит запрос, создает временный узел /lock,create -s /lock, Если узел существует, сервер ZK сообщит вам, что узел уже существует и не может быть создан повторно.get -w /lock/
  2. Запрос на получение блокировки обрабатывается и блокировка снимается, т.е.delete /lock/Узел, который в настоящее время получает блокировку, в это время будет уведомлять все подключения, прослушивающие узел, что является настоящей катастрофой в случае высокого параллелизма.

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

  честный замок:

  

  1. Когда приходит запрос, временный узел последовательности создается непосредственно под узлом /lock.
  2. Определите, являетесь ли вы самым маленьким узлом в узле /lock. Если он наименьший, блокировка приобретается. Если нет, следите за предыдущим узломget -w /lock/предыдущий узел
  3. Запрос на получение блокировки обрабатывается и блокировка снимается, т.е.delete /lock/Узел, который в данный момент получает блокировку, а затем узел, стоящий за ним, получит уведомление и повторит оценку на шаге 2.

4. Сравнение распределенных блокировок между ZK и Redis

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

1. скрипт setnx + lua

преимущество: Redis основан на памяти и имеет высокую производительность чтения и записи, поэтому эффективность распределенных блокировок на основе Redis относительно высока.

недостаток: в распределенной среде могут возникнуть проблемы с синхронизацией данных узла, и надежность оказывает определенное влияние. Например, сейчас есть кластер Redis с 3 мастерами и 3 кластерами, и команды, сгенерированные клиентом, записываются на машину 1.masterузла, когда данные готовятся к синхронизации главного сплетения,masterузел зависает,slaveУзел не получил последние данные, в это времяslaveВыбор узлаmaster, что приводит к сбою ранее добавленной распределенной блокировки.

2. Redission

преимущество: Решена проблема доступности синхронизации кластера Redis.

недостаток: В интернете написано: время релиза короткое, а стабильность и надежность еще предстоит проверить. Лично я считаю, что рынок в настоящее время стабилен, и это относительно зрелый и законченный распределенный замок.

Распределенный замок ZK

преимущество: Нет синхронизации данных redis (zookeeper возвращается после синхронизации), переключения master-slave (сервис недоступен в процессе переключения zookeeper master-slave), надежность очень высокая

недостаток: Гарантированная надежность при некотором снижении эффективности (но все равно очень высокой). Производительность не так хороша, как у Redis.

5. Выборы лидера кластера ZK

В кластерном режиме Zookeeper есть 3 типа ролей.

• Leader: Обрабатывает все запросы на транзакции (запросы на запись) и может обрабатывать запросы на чтение.В кластере может быть только один Лидер.
• Follower: он может только обрабатывать запросы на чтение и выступать в качестве узла-кандидата лидера, то есть, если лидер выходит из строя, узел-последователь будет участвовать в новых выборах лидера и может стать новым узлом-лидером.
• Observer: могут обрабатываться только запросы на чтение. не может участвовать в выборах.

Каждому запросу на обновление от клиента ZooKeeper присваивает глобально уникальный добавочный номер. Это число отражает последовательность всех транзакционных операций, и это числоZxid (идентификатор транзакции ZooKeeper).

Процесс избрания лидера

1. ZK внутри использует быстрый алгоритм выборов, который в основном зависит от двух факторов (миид, зхид), myid — это серийный номер кластера, хранящийся в файле конфигурации, а Zxid — идентификатор транзакции ZK.
2. Если предположить, что сейчас запущено два кластера ZK, а соответствующие им myid 1 и 2, то в процессе запуска будут происходить выборы лидера Процесс выборов выглядит следующим образом
3. Поскольку проект только стартовал, бизнеса нет. Следовательно, для машины с myid=1 подано голосов (1,0), а полученных голосов (2,0). Сравните полученные голоса с голосами, поданными ими самими. Принцип приоритета заключается в том, что наибольший Zxid является Лидером. , потому что чем больше Zxid, тем новее данные. Если Zxid одинаковый, по умолчанию выбирается лидер с большим myid, и в качестве лидера рекомендуется (2,0).
4. Для машины с myid=2 отдано (2,0) и получено голосов (1,0).Согласно приведенным выше правилам, (2,0) выбирается лидером.
5. Из-за ЗКправило больше половины, при достижении (Количество кластеров/2+1) Когда та же машина выбрана в качестве ведущей, измененная машина переключится из состояния «В поисках» в состояние «Лидер», а другие машины перейдут в состояние «Последователь».

Почему рекомендуется нечетное количество кластеров ZK?

1. Предполагая, что количество кластеров равно 4, один лидер умер, а последователей осталось 3. Из-за принципа более половины выборов лидера (3/2+1)=2 последователя должны проголосовать за одного и того же машина, чтобы стать лидером.
2. Предполагая, что количество кластеров равно 3, один лидер умер, а последователей осталось 2. Из-за принципа более половины выборов лидера (2/2+1)=2 последователя должны проголосовать за одного и того же машина, чтобы стать лидером.
3. Поскольку кластеру из 3 машин и 4 машин нужно, чтобы 2 последователя проголосовали за одну и ту же машину, чтобы стать лидером после смерти лидера, почему бы не сэкономить на стоимости одной машины?

Итак, в целом длясократить расходы.

Архитектура многоуровневой очереди для избрания лидера

Весь нижний слой выборов ZK можно разделить наВыбор прикладного уровняиуровень передачи сообщений

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

1. Прикладной уровень разработал единую очередь для отправки голосов (Очередь SendQueue прикладного уровня) и очередь на прием голосов (Прикладной уровень Очередь ReceiveQueue), затем включаетПоток WorkerSender прикладного уровнясканироватьОчередь SendQueue прикладного уровня, открытьПоток WorkerReceiver прикладного уровнясканировать транспортный уровеньОчередь ReceiveQueue транспортного уровня
2. Транспортный уровень поддерживает очередь отправки для всех машин в кластере ZK, кроме текущей машины, то есть каждая машина соответствует очереди отправки, а каждая очередь отправки соответствует потоку отправки, и эти потоки постоянно сканируют свои собственные очереди.
3. Поскольку каждая машина в кластере ZK установила длинную ссылку Soket, когда поток-отправитель сканирует новое сообщение для голосования, он отправит его на соответствующую машину через Socket.Поток ReceiveQueue транспортного уровня,ПотомПоток ReceiveQueue транспортного уровнясбросит сообщение в единыйОчередь ReceiveQueue транспортного уровняв, когдаПоток WorkerReceiver прикладного уровнясканировать вОчередь ReceiveQueue транспортного уровняКогда новости отправляются, она пересылает сообщениеОчередь ReceiveQueue прикладного уровня
4. Итоговая статистика голосов, выборы Лидер.

Бао, есть сомнения, зачем ЗК это сделал?

1. Асинхронность повышает производительность.
2. Очереди разделены по машинам-отправителям, чтобы избежать взаимного влияния при отправке сообщений на каждую машину.Например, если какая-то машина не может отправить сообщения, это не повлияет на отправку сообщений на обычные машины.

5. Проблема разделения мозга ЗК

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

Что такое расщепленный мозг?

Проще говоря, в обычном ZK-кластере есть только один Лидер, и этот Лидер является мозгом всего кластера.Сплит-мозг, как следует из названия, разделяет мозг, который производит несколько Лидеров.

Описание сценария ZK split brain

Для кластера, для повышения доступности кластера, его обычно разворачивают в нескольких машинных залах, например, сейчас есть кластер из 6 ЗК, развернутых в двух машинных залах:

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

Это эквивалентно исходному одному кластеру, разделенному на два кластера, было два «мозга», что называется «расколотый мозг«Явления. В данном случае действительно видно, что это должен был быть единый кластер для предоставления внешних услуг, но теперь стало два кластера для предоставления внешних услуг одновременно, если через некоторое время отключенная сеть вдруг подключится., то в это время будут проблемы.Оба кластера только что предоставили услуги внешнему миру, как сливать данные, как решать конфликты данных и тд.

При объяснении сценария с разделенным мозгом только что есть предварительное условие, что механизм over-half не рассматривается, поэтому на самом деле проблема разделения мозга не будет легко возникать в кластере Zookeeper из-за механизма over-half.

Почему механизм большинства ZK больше, а не больше или равен?

Это связано с проблемой разделенного мозга.Например, вернемся к приведенному выше сценарию, где возникает проблема разделенного мозга: когда сеть в середине компьютерного зала отключена, три сервера в компьютерном зале 1 будут проводить лидера выборы, но на данный момент более половины механизма Условие "количество узлов > 3", то есть для выбора лидера требуется не менее 4 zkServers, поэтому он не может выбрать лидера для машинного зала 1, а также не может выбрать лидера для компьютерного зала 2. В этом случае После отключения сети в аварийном зале всего кластера у всего кластера не будет лидера. А если условием механизма большинства является «количество узлов >= 3», то и машинный зал 1, и компьютерный зал 2 выберут лидера, что вызовет расщепление мозга. Это может объяснить, почему мажоритарный механизм скорее больше, чем больше или равен, цельЧтобы предотвратить расщепление мозга.

Если предположить, что у нас сейчас всего 5 машин, тоже развернутых в двух машинных залах:В это время условие более половины механизма - "количество узлов > 2", то есть для выбора лидера требуется не менее 3 серверов.В это время сеть компьютерного зала отключена, что никак не влияет на машинный зал 1, а лидер все равно остается.Лидер, для компьютерного зала 2, лидера выбрать нельзя.В это время во всем кластере есть только один лидер. Таким образом, можно сделать вывод, что при механизме более половины для кластера ZK либо нет лидера, либо только один лидер, так что ZK также может избежать проблемы разделения мозга.

6. Знаменитый протокол ZAB

Что такое протокол ZAB?

Протокол ZAB — это протокол, специально разработанный для ZK.Согласованный протокол, поддерживающий восстановление после сбоя. На основе этого протокола ZK реализует системную архитектуру ведущий-ведомый для поддержания связи между репликами в кластере.согласованность данных.

В распределенных системах обычно используется модель системной архитектуры master-slave, что означает, что ведущий сервер отвечает за запросы на запись внешних клиентов. Тогда все остальное - это сервер Follower. Ведущий сервер синхронизирует данные операции записи клиента со всеми узлами-ведомыми.

Таким образом, все запросы на запись, отправленные клиентом, отправляются ведущему, и после того, как ведущий запишет данные, они пересылаются ведомому. На данный момент необходимо решить две проблемы:

1. Как ведущий сервер обновляет данные для всех последователей.
2. Внезапно выходит из строя сервер Лидер, что делать?

Для решения двух вышеуказанных проблем протокол ZAB разработал два режима:

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

2. режим восстановления после сбоя: Как восстановиться при сбое Лидера

режим рассылки сообщений

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

1. Лидер превращает Запрос клиента в Предложение
2. Лидер готовит очередь FIFO для каждого Последователя и Наблюдателя и отправляет Предложение в очередь.
3. Последователь и Наблюдатель берут Предложение во главе очереди и возвращают ACK Лидеру.
4. Если Лидер получает более половины отклика ACK, Лидер выполняет операцию CommIT и отправляет CommIT всем Последователям и Наблюдателям.
5. Последователи и наблюдатели выполняют операции фиксации.

Это весь шаблон широковещательной рассылки сообщений. Давайте начнем с того, что произойдет, если ведущий узел выйдет из строя во время процесса рассылки сообщения? Можно ли гарантировать согласованность данных? Что делать, если лидер сначала отправляет локально, а затем запрос на коммит не отправляется? То есть второй режим: режим аварийного восстановления.

режим восстановления после сбоя

крах:То есть, если Лидер потеряет контакт с более чем половиной Последователей, то начнется новый тур выборов, и первым будет избран новый Лидер..

Поскольку требуется восстановление, некоторые сценарии не могут быть восстановлены.Требования к аварийному восстановлению протокола ZAB соответствуют следующим двум требованиям:

1. Обязательно отбрасывайте предложения, отправленные только в ведущем, но не в ведомом.
2. Убедитесь, что транзакции, которые были совершены лидером, в конечном итоге будут совершены всеми последователями.

Ну а теперь приступим к восстановлению.

1. Выбранный новый лидер имеет наибольший Zxid, а это значит, что текущая транзакция является самой последней.
2. Новый лидер отправляет это предложение о событии другим узлам-последователям.
3. Узел Последователя будет действовать в соответствии с сообщением Лидера.Откат или синхронизация данныхработать. Конечная цель — обеспечить согласованность копий данных всех узлов в кластере.

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