С развитием интернет-технологий для крупномасштабных веб-сайтов требуется все большая и большая вычислительная мощность и объем памяти, а архитектура веб-сайта постепенно меняется с централизованной системы на распределенную.
Хотя у распределенных есть много преимуществ по сравнению с централизованными системами, такие как более высокие и мощные вычислительные возможности, возможности хранения и обработки. Но это также приводит к другим проблемам, например, как обеспечить согласованность и доступность данных в распределенной системе.
В повседневной жизни, если два сотрудника или пользователя не согласны с чем-то, обычно наш подход заключается в том, чтобы найти начальника для синхронизации данных и информации.
Итак, что касается нашего сервиса, как справиться с рассинхронизацией данных между несколькими узлами?
В процессе перехода от одной машины к кластеру и распределенным службам каждая технология или инструмент двигались по систематическому и специализированному пути. Например, в монолитном приложении, если несколько потоков хотят изменить одну и ту же переменную, наш обычный подход состоит в том, чтобы заблокировать изменяемую переменную или ресурс. Так что для кластеров такой вещи нет, что нам делать?
Для распределенных кластеров в настоящее время нам обычно требуетсяМежду различными службами или узламипровестикоординацияизслужба или посредник
В архитектурном проектировании нет проблемы, которая не могла бы пройти через один слой.уровень абстракцииЧтобы решить, если есть, это два слоя.
Посмотрим вместе, руководитель службы координации - ZooKeeper
происхождение зоопарка
Изначально в экосистеме Hadoop будет много сервисов или компонентов (таких как hive, pig и т. д.), и координировать обработку между каждым сервисом или компонентом очень проблематично. высокопроизводительные данные, сильная согласованность, гендерная координационная структура. Поэтому инженеры Yahoo создали эту промежуточную программу, но название промежуточной программы обеспокоило разработчиков.Я вдруг подумал, что большинству названий животных в хаупе как будто не хватает администратора.Настолько похожи функции этой программы. Так родился смотритель зоопарка.
Какие функции предоставляет zookeeper для облегчения обработки возможностей координации?
Функции и особенности
хранилище данных
Zookeeper предоставляет структуры данных, аналогичные файловым системам Linux. Каждый узел соответствует узлу Znode, и каждый узел Znode может хранить 1 МБ (по умолчанию) данных.
Операция клиента на zk — это операция на узле Znode.
- Znode: содержит контроль разрешений ACL, время модификации/доступа, идентификатор транзакции (zxid) последней операции и т. д.
- Говорят, что в памяти хранятся данные, и такое дерево поддерживается в памяти.
- Каждая модификация узла Znode — это операция, гарантирующая порядок и атомарность. Операции записи являются атомарными операциями.
Например, в реестре всех провайдеров «сервиса 1» можно найти по пути «/fsof/servicename1/providers».
Каждый узел имеет Znode в соответствии с узломжизненный циклитипДелится на 4 типа узлов.
- Жизненный цикл: когда сеанс клиента завершается, нужно ли очищать узлы, созданные этим сеансом. Постоянный — без очистки, временный — с очисткой.
- Тип: для каждого сеанса создавать отдельные узлы (примеры: обычные узлы: rudytan, узлы с последовательными номерами: rudytan001, rudytan002 и т. д.)
механизм мониторинга
Помимо предоставления возможностей обработки для узлов Znode, zookeeper также предоставляет возможность отслеживать и уведомлять об изменениях в узлах.
Этапы механизма мониторинга следующие:
- Любая сессия (session1, session2) может отслеживать интересующие ее znode.
- Когда znode изменяет узел через session1.
- И session1, и session2 получат уведомление о событии изменения znode.
Общие уведомления о событиях для узлов:
- событие успешного установления сеанса
- узел добавить
- Удаление узла
- Изменение узла
- изменения списка дочерних узлов
Особо следует отметить:
Событие прослушивания будет запущено только один раз.Если вы хотите прослушать второе изменение znode, вам необходимо перерегистрировать прослушиватель.
На данный момент мы узнали о возможностях, предоставляемых zookeeper, в каких сценариях мы можем его использовать? Как это использовать?
Сценарии применения
Zookeeper может больше использоваться для управления кластером, регистрации служб и обнаружения микрослужб.
Регистрационный центр
- зависит отвременный узел
- Когда потребитель запустится, он сначала отправится в центр регистрации, чтобы получить список регистрации полного сервиса.
- При изменении сервисного узла передатьмеханизм мониторингаСделайте обновление данных.
- Zookeeper вешает трубку и не влияет на звонки в службу поддержки.
Есть еще популярный сервис Эврика, который тоже можно использовать как регистрационный центр, в чем их преимущества и недостатки? Просто вопрос, ха-ха.
Распределенная блокировка
- зависит отУзел временной последовательности
- Определите, является ли порядковый номер текущего клиента наименьшим, и если да, то блокировка получена.
- Узел, который не получил блокировку, прослушивает событие удаления наименьшего узла (например, lock_key_001).
- Блокировка снимается, наименьший узел удаляется, а оставшиеся узлы перезапускаются для получения блокировки.
- Повторите шаги и четыре.
Redis и db также могут создавать распределенные блокировки, в чем сходство и различие? Просто вопрос, ха-ха.
Распределенные блокировки можно посмотреть в другой моей статье: Распределенные блокировкиу-у-у. Краткое описание.com/afraid/oh 4174 oh 499…
Управление кластером и главные выборы
- зависит отвременный узел
- гарантия зоопаркаНевозможно дублировать существующий узел данных, успешно созданный клиент является ведущим.
- Не мастер, на уже созданных узлахЗарегистрируйтесь на событие удаления узламонитор.
- Когда мастер зависает, другие кластерные узлы получают событие удаления узла и проводят переизбрание
- Повторить шаги от двух до четырех
Конечно, есть и другие сценарии применения, которые не перечислены один за другим.
Кто-то говорит, что zookeeper можно использовать как распределенный центр конфигурации и распределенную очередь сообщений, увидев здесь друзей, вы считаете, что это подходит?
На этом теоретический запас знаний, основанный на разработке приложений zk, может быть в основном удовлетворен. Друзья, которым больше интересен этот принцип или у которых более сильное любопытство, могут продолжить чтение, а затем рассказать о том, как zookeeper достигает высокой производительности, высокой доступности и строгой согласованности.
Гарантия высокой производительности, высокой доступности и строгой согласованности
Высокая производительность — распределенный кластер
Для высокой производительности мы обычно думаем о разрушении узкого места производительности одной машины через развертывание кластера. Для ZK, именно для обеспечения высокопроизводительного чтения, развертывая несколько узлов для предоставления услуг внешней миру.
- Режим ведущий/ведомый.
- Разверните несколько узлов в zookeeper для предоставления внешних служб, и клиенты смогут подключаться к любому узлу.
- Данные для каждого узла одинаковы.
- Узлы делятся на узлы-лидеры и узлы-учащиеся (включая узлы-последователи и узлы-наблюдатели) в соответствии с их ролями.
- В кластере есть только один узел-лидер, который выполняет всю обработку запросов на запись.
- Каждый запрос на запись генерирует глобально уникальный 64-битный целочисленный идентификатор транзакции (который можно понимать как номер версии глобальных данных).
- Узлов Ученика может быть много, и каждый Ученик может независимо обрабатывать запросы на чтение и передавать запросы узлу-лидеру.
- Когда узел-лидер зависает, из узлов-последователей будет выбран лидер для предоставления внешних услуг.
- Отличие узла Follower от узла Observer в том, что он не участвует в выборах и обрабатывается более половины предложенных транзакций.
- Кластеры обычно развертываются в соответствии с нечетным числом узлов (иногда слишком малое влияние на аварийное восстановление, пустая трата машин).
Консистентность данных (протокол zab — протокол атомарного вещания)
Из-за развертывания кластера по принципу CAP это может привести к несогласованности данных одних и тех же данных на разных узлах. Zookeeper использует атомарный широковещательный протокол zab для обеспечения согласованности данных на каждом узле. Протокол атомарной широковещательной рассылки (похожий на протокол фиксации 2PC) грубо разделен на 3 этапа.
- Лидер упаковывает запрос на запись, генерирует уникальный zxid, инициирует предложение и транслирует его всем подписчикам.
- После того, как фолловер получает предложение, он пишет в локальный журнал транзакций, и в соответствии со своей ситуацией, соглашаться ли на отправку транзакции.
- Лидер получает согласие более половины Подписчиков и первым добавляет транзакцию. Затем отправьте запрос на фиксацию транзакции всем узлам Learner.
Следует отметить, что требования zookeeper к согласованности данных:
- Последовательная согласованность: операции записи выполняются строго в том порядке, в котором транзакции были инициированы.
- Атомарность: результаты всех запросов транзакций последовательно применяются ко всем узлам в кластере.
- Одиночный просмотр: клиенты получают доступ к любому узлу и смотрите ту же модель данных.
- В режиме реального времени: гарантируется, что клиент наконец сможет прочитать последний статус данных из службы за очень короткий период времени (если это должно быть в режиме реального времени, клиенту необходимо вызвать метод syn).
Доступность - выборы лидера (протокол заб - протокол восстановления после сбоя)
Во всем кластере запросы на запись концентрируются на узле-лидере, что делать, если узел-лидер завис?
Когда кластер инициализирован или ведомый не может связаться с узлом-лидером, каждый ведомый начинает входить в режим выборов. Этапы выборов следующие:
- Узел-последователь голосует за себя в первый раз, а затем передает свой голос оставшимся узлам-последователям.
- Последующий узел получает дополнительные голоса.
- Сравнение бюллетеня: сравните свои собственные голоса с полученными голосами.
- Если голос фонда не является наиболее предпочтительным голосом, измените его собственный голос и проголосуйте за узел с наиболее предпочтительным голосом.
- Подсчитайте голоса, полученные самостоятельно, если узел набрал голоса более половины узлов. Подтвердите, что этот узел является новым ведущим узлом.
- После подтверждения узла-лидера каждый узел меняет свою роль. Завершите голосование.
Принцип выборов: тот, у кого есть последние данные, имеет приоритет на избрание лидером.
Например, если в zk кластере сейчас 5 узлов, а потом зависают 2 узла. Остальные узлы S3, S4 и S6 начинают выбирать, и их максимальные идентификаторы транзакций равны 6, 2 и 6 соответственно. Определите структуру голосования как (идентификатор узла для голосования, идентификатор узла для голосования, максимальный идентификатор транзакции узла для голосования).
- В начальном состоянии S3, S4 и S5 голосуют за себя соответственно и вносят свой собственный максимальный идентификатор транзакции.
- S3, S4 и S5 сравнивают 2 голоса, которые они получили, с их 1 голосом соответственно.
- S5 считает, что это оптимальное голосование и не меняет голос S3 и S4 считают, что голосование S5 является оптимальным решением, и меняют голосование.
- S3, S4 транслируют свои собственные голоса за изменение.
- Наконец, все подтвердили, что S5 является лидером, состояние узла S5 изменено на узел-лидер, а узлы S3 и S4 изменены на узлы-последователи.
Здесь является основным процессом выборов.
сохранение данных
- Все данные зоопарка хранятся в памяти.
- zookeeper будет периодически сбрасывать память на диск, формируяснимок данных.
- Каждый запрос транзакции zookeeper будет сначала подключен к диску для формированияЖурнал транзакций.
- Полные данные = моментальный снимок данных + журнал транзакций.
сравнивать
Как упоминалось ранее, существует множество альтернатив для различных сценариев применения, поэтому давайте проведем простое сравнение.
Сравнение реестров (со схемой Eureka от Netflix)
На приведенной выше архитектурной диаграмме видно, что Eureka отличается от узлов в zk, и каждый узел в Eureka является одноранговым. Это система AP, а не система zk CP.В сценарии применения реестра нас больше заботит доступность, чем строгая согласованность данных.
Распределенная блокировка (по сравнению с redis, mysql)
Распределенные блокировки можно найти в другой моей статье: Распределенные блокировки (redis/mysql)у-у-у. Краткое описание.com/afraid/oh 4174 oh 499…
Сравнение конкретных различий:
- Redis: простой, не очень надежный
- DB: Стабильный, не хватает производительности
- ZK: Относительно высокая производительность и полная реализация блокировки, но высокая сложность реализации и низкий уровень параллелизма.
С помощью этих сравнений, почему нам все еще нужен или в каких сценариях мы используем zookeeper. Я думаю, всего одна фраза:
zookeeper, решение службы распределенной координации общего назначения.
понимание
Наконец, давайте поговорим о понимании всего процесса обучения и использования zk.
- Универсальной пули не существует, и у каждой технологии или решения есть свои преимущества и недостатки.
- Легко делать что-то одно, но трудно делать что-то хорошо.
Я тут все это видел, обратите внимание на паблик, давайте обмениваться и учиться вместе