Я думаю, что все слышали о ZooKeeper, возможно, вы не использовали его непосредственно в разработке, но широко используемые Hadoop, HBase, Kafka, Dubbo и т. д. все используют ZooKeeper. Итак, какую роль играет ZooKeeper, почему эти фреймворки и системы должны использовать ZooKeeper, как мы должны использовать ZooKeeper в процессе разработки и есть ли альтернативы ZooKeeper. В этой статье основное внимание будет уделено вышеупомянутым вопросам и начнется со следующих трех аспектов:
- источник и функция;
- Классические сценарии применения;
- заменять.
1. Происхождение и роль
Для чего был разработан ZooKeeper? Все начинается с исследовательской группы в Yahoo. В то время исследователи обнаружили, что многие распределенные системы в Yahoo должны были полагаться на компонент для распределенной координации, но эти компоненты часто имели распределенные одноточечные проблемы. Так Yahoo организовала разработкуОбщая распределенная координационная структура без единой проблемы, то есть ZooKeeper, с одной стороныпроблема с одной точкой, с другой стороны, будетРаспределенная координацияиз распределенной системыотстранитьсяВыходи, пусть разработчики больше сосредотачиваются на бизнес-логике.
Ниже описаны «проблема одной точки» и «распределенная координация».
1.1 Проблема с одной точкой
Единая точка отказа (также называемая единой точкой отказа, SPOF) относится к компоненту в системе, отказ которого приведет к неработоспособности всей системы. Например, если система развернута только на одной машине, машине А, если машина А выйдет из строя, вся система не будет работать. Чтобы решить эту проблему, обычно используется избыточный метод и добавляется несколько машин.Пока несколько машин не выходят из строя одновременно, система будет работать нормально.
ZooKeeper также решает одноточечные проблемы кластерным способом. Кажется, что развернув в кластере еще несколько машин, можно решить одну проблему. Во-первых, нам нужно уточнить одноточечную задачу доОдноточечная проблема без сохранения состоянияиОдноточечная проблема с состоянием. Упомянутое здесь состояние может относиться к концепции сетевых протоколов, HTTP-протокола без сохранения состояния, каждый запрос является независимым, TCP-протокол с отслеживанием состояния, полагаясь на состояние записи для завершения надежной передачи.
Простые одноточечные проблемы без сохранения состояния можно решить с помощью кластеризации.Например, прокси-узел выполняет пересылку сообщений, что представляет собой ситуацию без сохранения состояния, как показано на следующем рисунке:
Если сервер пересылки сообщений X выходит из строя, сервер Y может продолжать нормально работать, и чем больше количество машин, тем выше доступность.
Для случая с состоянием он отличается и столкнется сРаспределенная согласованностьпроблема. Проблема не может быть решена простым добавлением машин. Общие решения:
- De-state: удалить проблему как не имеющую состояния, например, сохранить состояние в надежной БД;
- Master-slave: Мастер выполняет основную обработку данных, а ведомый синхронизирует состояние ведущего, например репликацию ведущего-ведомого MySQL, ведущий обрабатывает операции записи, а ведомый синхронизирует состояние через binlog.
Вышеприведенное кратко представляет решение MySQL, а ZooKeeper использует протокол ZAB для достижения согласованности. Что касается вопроса распределенной консистентности, в этой статье мы не будем продолжать его описывать, каждый должен помнить в первую очередьZooKeeper решает проблему одной точки и может гарантировать согласованность, не беспокойтесь о том, что кластер ZooKeeper вызовет проблемы несогласованности данных из-за простоя машины.
После обсуждения проблемы одной точки давайте поговорим о распределенной координации, которая также необходима ZooKeeper.
1.2 Распределенная координация
Распределенная координация, как это буквально означает, координируется в распределенной среде. Например, в случае одной машины, если несколько потоков хотят изменить ресурс одновременно, например, инвентарь минус один. Для обеспечения корректности мы добавим блокировку на этот ресурс. Но в распределенной ситуации, если несколько машин хотят изменить ресурс, как нам заблокировать ресурс? Тогда вам нуженкоординаторвнешний вид. Если машина хочет знать, заблокированы ли другие машины, ей не нужно связываться с другими машинами.Ей нужно только связаться с координатором, чтобы узнать статус блокировки ресурсов, и также можно считать, что блокировкой управляет координатор.
Вы можете сказать, почему ZooKeeper является координатором и почему бы просто не выбрать машину в кластере. Да, конечно, но тогда нужно решить одноточечную задачу координатора (машина, выступающая в роли координатора, выходит из строя). А поскольку большинству распределенных систем нужен такой компонент-координатор, а для повторного использования он извлекается, то естьРаспределенная система координации. Поэтому такие фреймворки, как Dubbo и Kafka, используют ZooKeeper напрямую при реализации раздачи, так что нет необходимости повторять реализацию компонента-координатора. Как программисты, нам нужно сосредоточиться только на реализации бизнес-логики в распределенной разработке.
Подводя итог, роль ZooKeeper заключается в предоставлении службы распределенной координации без единой проблемы.
2. Классические сценарии применения
В этом разделе будут представлены некоторые классические сценарии применения ZooKeeper и показано, как использовать ZooKeeper, но прежде всего вам необходимо иметь определенное представление о модели данных ZooKeeper, характеристиках узлов и механизме Watcher, которые будут кратко представлены ниже.
2.1 Основы ZooKeeper
Под моделью данных можно понимать форму хранения данных, например, Redis хранит данные в виде пар ключ-значение, а ZooKeeper — в виде дерева, как показано на следующем рисунке:
Имя корневого узла "/", корневой узел имеет два дочерних узла "A" и "B", а "A" имеет три дочерних узла "X", "Y", "Z". Мы можем организовать узлы дерева в соответствии с нашими потребностями, а также хранить данные в узлах.Это немного похоже на файловую систему?
Имея базовое понимание модели данных, вам также необходимо знать характеристики следующего узла.Существует 4 типа узлов, каждый из которых легко понять:
- Постоянный узел: он всегда будет существовать после создания, если только он не будет активно удален;
- Постоянный последовательный узел: его постоянство такое же, как и у постоянного узла, но оно последовательное.К имени узла добавляется цифровой суффикс, чтобы указать порядок, в котором он был создан, например 1, 2, 3, 4. ..;
- Временный узел: в случае сбоя сеанса, создавшего узел, узел также будет удален;
- Временные узлы последовательности: к временным узлам добавлено понятие последовательности.
Наконец, давайте знать, что механизм Watcher — это механизм мониторинга.Мы можем отслеживать изменения в содержании данных узла, изменения в дочерних узлах и т. д. Как только события, которые мы отслеживаем, происходят, ZooKeeper уведомляет нас.
Познакомившись с некоторыми основами ZooKeeper, давайте перейдем к теме этого раздела.
2.2 Публикация/подписка на данные
пройти черезНаблюдательный механизмРеализовать публикацию/подписку на данные. Возьмем в качестве примера сценарий центра конфигурации. Опубликуйте конфигурацию на узлах ZooKeeper, и другие машины смогут динамически обновлять конфигурацию, отслеживая изменения узлов на ZooKeeper. Например, мы помещаем конфигурацию базы данных в узел «/configserver/app1/database_config», а затем позволяем каждой машине получать информацию о конфигурации базы данных из узла при ее запуске и отслеживать изменения содержимого узла. , повторно получить конфигурацию .
2.3 Службы имен
через ZooKeeperпоследовательный узелСоздайте глобально уникальный идентификатор. Например, распределенная система планирования задач создает глобально уникальные идентификаторы для задач, как показано на следующем рисунке:
После создания узла последовательности имя задания с уникальным идентификатором можно получить, объединив имена узлов, например "type1-job-000000003".
2.4 Управление кластером
через ZooKeeperвременный узелиНаблюдательный механизм, чтобы отслеживать рабочее состояние кластера, как показано на следующем рисунке:
Когда к кластеру присоединяется новая машина, в разделе «Машины» создается временный узел. Когда машина выйдет из строя, временный узел выйдет из строя и будет удален. Отслеживая изменения дочерних узлов в разделе «машины», вы можете узнать состояние машин кластера.
2.5 Распределенная блокировка
Существует два основных типа распределенных блокировок: эксклюзивные блокировки и разделяемые блокировки.
Эксклюзивная блокировка в период, когда транзакция блокирует ресурс, не позволяет другим транзакциям выполнять операции чтения и записи. черезвременный узелОн может представлять замок, как показано на следующем рисунке:
Создание узла «блокировка» в узле «resourceA\exclusive_lock» указывает на то, что монопольная блокировка размещена на ресурсе A. Когда несколько компьютеров пытаются создать узел «блокировки» под «exclusive_lock», только один из них добьется успеха, а другие отказавшие машины будут прослушивать изменения в дочерних узлах «exclusive_lock». Когда блокировка активно снимается или происходит сбой, узел «замок» будет удален, а другие машины будут уведомлены и продолжат попытки создать узел «замок», чтобы получить блокировку.
Общие блокировки позволяют другим транзакциям выполнять операции чтения, пока транзакция блокирует ресурс. Блокировка по-прежнему представлена узлом. Разница в том, что операции чтения и записи необходимо различать. Операции чтения и записи могут быть представлены содержимым данных узла. Например, R представляет операции чтения, а W представляет операции записи. Как показано ниже:
Операции чтения и записи создаются в узле «shared_lock» с именем «lock».Узел временной последовательности, но содержимое данных отличается. Для операций чтения, если все дочерние узлы с меньшим порядковым номером, чем их собственный, являются запросами на чтение, считается, что блокировка была успешно получена и операция чтения может быть выполнена.Если узел с меньшим порядковым номером содержит запрос на запись операции, он должен ждать и отслеживать дочерние элементы «shared_lock». Для операций записи, если это не дочерний узел с наименьшим порядковым номером, он будет ожидать и прослушивать изменения в дочернем узле «shared_lock».
3. Альтернативы
Во втором разделе мы узнали, что ZooKeeper имеет много сценариев применения в распределенной среде.Нужно ли использовать ZooKeeper для реализации таких функций, как распределенные блокировки и управление кластером? Конечно нет, есть и другие технологии на выбор. Например, Redis также можно использовать для распределенных служб координации.Все сценарии, упомянутые в разделе 2, достижимы, но их необходимо разрабатывать по-разному из-за разных моделей данных.
Итак, мы используем ZooKeeper или Redis? Это нужно решать по сценарию.Давайте сравним преимущества и недостатки того и другого в сценарии с распределенными блокировками:
- Redis: поддерживает одновременное получение и освобождение операций блокировки, не может гарантировать 100% согласованность данных и может иметь проблемы (очень мало);
- ZooKeeper: модель блокировки является надежной и последовательной, но частые операции по применению и снятию блокировки создают большую нагрузку на кластер ZooKeeper.
Согласованность данных Redis не так хороша, как у ZooKeeper, а поддержка параллелизма в ZooKeeper не так хороша, как у Redis.
Наконец, я хотел бы представить etcd — высокодоступную систему хранения данных типа «ключ-значение», написанную на Go и использующую алгоритм Raft для обработки репликации журналов для обеспечения строгой согласованности, и используемую такими системами, как Kubernetes. По сравнению с ZooKeeper есть много отличий в технических деталях.Приведу несколько общих.ZooKeeper реализован на основе Java,и естественно имеет недостатки Java,такие как GC pause,в то время как etcd использует хранение вне кучи,куча он не будет управляться сборщиком мусора, поэтому проблем с приостановкой сборщика мусора не возникает. ZooKeeper имеет хорошую клиентскую библиотеку Java, а также предоставляет клиентские библиотеки на других языках.Как восходящая звезда, etcd, хорошей клиентской библиотеки Java нет, и ее можно вызывать только через HTTP.
Приведенный выше список Redis и etcd предназначен только для того, чтобы помочь читателям расширить свой кругозор, не ограничиваясь ZooKeeper. А как проводить конкретный технический отбор, опыта у автора еще не хватает, так что больше говорить не буду.
4. Ссылка
- «От Паксоса до ZooKeeper»
- Зачем вам нужен ZooKeeper
Друзья, которым нравятся мои статьи, вы можете отсканировать код и подписаться на мой официальный аккаунт: "Травяной щипок"