Принцип и применение зоозащитника

ZooKeeper

ZooKeeper — это распределенная служба координации распределенных приложений с открытым исходным кодом,GoogleизChubbyРеализация с открытым исходным кодом.

Apache ZooKeeper is an effort to develop and maintain an open-source server which enables highly reliable distributed coordination.

Принцип введение и объяснение

  • алгоритм консенсуса

ZooKeeper以Fast Paxos(Paxos) для обеспечения согласованности данных для каждого экземпляра zk в кластере. Как правило, развертывается кластер, а количество машин устанавливается равным нечетному числу, что легче удовлетворить условию голосования > N/2.

  • модель хранения
/
├── app1
│   ├── p_1
│   ├── p_2
│   └── p_3
└── app2

Подобно древовидной модели папок операционной системы, отличие от папок в том, что данные могут храниться на каждом узле (не более1M), данные на каждом узле могут содержать номер версии.

  • zNodeТип узла

2Измерение деления: в зависимости от того, может ли узел быть постоянно сохраненным, разделенным на постоянные узлы и временные узлы, в зависимости от того, может ли серийный номер узла последовательно увеличиваться (аналогичноmysqlизauto_increment), разделенные на последовательные узлы и непоследовательные узлы,

Примечание. После версии 3.6.0 новыеContainer Nodes(узел-контейнер), который характеризуется тем, что если все дочерние узлы под ним будут удалены, то узел также будет удален когда-то в будущем.

ZooKeeper has the notion of container nodes. Container nodes are special purpose nodes useful for recipes such as leader, lock, etc. When the last child of a container is deleted, the container becomes a candidate to be deleted by the server at some point in the future.

постоянный узел(clientПосле создания постоянного узла, даже сzkотключен, узел остается вzkсередина)

Постоянные последовательные узлы(eg: /order/quartz/wm000001 , /order/quartz/wm000002, /order/quartz/wm000003...)

временный узел(clientиzkПосле отключения узел автоматически удаляется)

Узел временной последовательности

  • прослушиватель событий
    • Created event(событие создания узла)
    • Deleted event(событие удаления узла)
    • Changed event(событие изменения данных узла) -zkClient.subscribeChildChanges();//Подписка на изменения в дочерних узлах
    • zkClient.subscribeDataChanges();//Подписка на события изменения данных узла (включая удаление данных)
    • zkClient.subscribeStateChanges();//Статус заказа меняется (состояние включает в себя: подключение, отключение, сбой аутентификации и т.д.)

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

  • ACL(Access Control List)Контроль доступа

    • Каждый узел имеет 5 разрешений на операции:Create、Read、Write、Delete、Adminкороткое имяcrwda. в:DeleteЭто относится к тому, имеет ли дочерний узел разрешение на удаление, а остальные четыре разрешения относятся к разрешению на операцию собственного узла.
    • Метод проверки подлинности:world：Режим по умолчанию, неограниченный, доступный по всему миру.auth：Добавьте авторизованных пользователей в контекст.digest：Аутентификация по имени пользователя/паролюip: ipпроверка подлинности адреса

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

  • Сценарий приложения 1: распределенная конфигурация

ВАЖНО: Информация о конфигурации сохраняется вdbиzkПосередине (для подстраховки безопасность данных выше) получите интерфейс фонового управления, а после модификации конфигурации сохраните ее вdb, затем напишите синхронноzkв узле. Когда приложение запустится, подключитесь кzkЧитайте конфигурацию в узле и одновременно отслеживайте изменение данных узла и получайте уведомления в режиме реального времени при изменении конфигурации.

  • Сценарий приложения 2: устранение единых точек отказа(Single Point of Failure，SPOF) 
└── ./OrderNoService
        ├── A0000001
                10.0.0.1:8001
        └── A0000002
                10.0.0.2:8001

Несколько экземпляров службы, которые запускаются вzkНа временном узле последовательности вызывающая сторона соглашается взять наименьший узел в качествеMaster,когдаmasterПосле завершения соединения узел автоматически удаляется, вызывающий абонент уведомляется о событии, и для вызова используется новый минимальный узел.(эквивалентноslaveПовышен доmaster)

  • Сценарий приложения 3: децентрализация

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

  • Сценарий приложения 4: распределенная блокировка
Order
    └── 3456890
        ├── 000001
        ├── 000002
        └── 000003

Принцип: запуск экземпляров нескольких программ при обработке заказов.3456890Например, перед тем, как каждая программа запускает обработку экземпляра, создайте временный узел последовательности, а затем проверьте, является ли созданный вами узел наименьшим, если нет, то это означает, что блокировка не захвачена, если да, то это означает, что блокировка захватывается, и программа, захватившая блокировку, обрабатывается, после чего удаляем узел, чтобы снять блокировку. В то же время другие программы в состоянии ожидания прослушивают родительский узел, чтобы получить уведомление об освобождении блокировки в режиме реального времени.Order/3456890Когда дочерний узел изменится, когда дочерний узел изменится, повторите процесс обнаружения только сейчас, пока созданный вами узел не станет самым маленьким. иredis SETNXПо сравнению с распределенными блокировками, такими какzkРаспределенный замокTop Nтакие как проблемы ограниченного доступа к ресурсам (аналогично семафорам в параллелизме). Например: нужно напечатать кучу программ, а принтеров всего 2 (или длина очереди на печать всего 2, и максимум 2 программам можно разрешить отправлять задания на печать одновременно), аналогично по идее только что самые маленькие первые 2 узла могут быть обнаружены, только программа которая создает минимальные первые 2 узла считается получившей сигнал, разрешающий подачу задания на печать.

  • Сценарий приложения 5: распределенная очередь
Queue
    └── Queue1
        ├── 000001
        ├── 000002
        └── 000003

Как показано выше, создайтеQueue/Queue1как очередь (илиTopic), и затем каждый раз, когда создается последовательный узел, он рассматривается как сообщение (данные, хранящиеся в узле, являются содержимым сообщения), и производитель каждый раз создает новый узел, который отправляется как сообщение, и потребитель слушает его.Queue1При изменении дочернего узла (или опросе по времени) в качестве сообщения потребления каждый раз берется наименьший узел, после обработки узел удаляется. эквивалентно реализацииFIFOочередь (первым пришел, первым ушел). Примечание:zkФреймворк обеспечивает этоCP(Согласованность), не предназначенный для сценариев с высокой степенью параллелизма и высокой производительностью, если в высокой степени параллелизма,qpsПри высоких условиях следует рассматривать распределенную очередь как подходящую.

  • Сценарий приложения 7: Создание распределенного уникальногоid 
Order
      └── OrderId
        ├── 000001
        ├── 000002
        └── 000003

Идея: Каждый раз новыйId, создать постоянный узел последовательности, а порядковый номер узла, возвращенный операцией создания, является новымId, а затем удалите узел меньше вашего собственного.

последняя глава

В настоящее время многие проекты с открытым исходным кодом в большей или меньшей степени полагаются наzookeeper,Например:dubbo，disconf，kafka，...

В распределенной средеzkКакие сценарии для этого можно использовать, в основном зависит от фантазии разработчика!

Категории