Что такое ZooKeeper?
ZooKeeper — это проект верхнего уровня Apache, предоставляющий эффективные и высокодоступные распределенные службы координации для распределенных приложений, обеспечивающие распределенные основы, такие как публикация/подписка данных, балансировка нагрузки, службы именования, распределенная координация/уведомление и распределенное обслуживание блокировок. ZooKeeper широко используется в крупных распределенных системах, таких как Hadoop, HBase, Kafka и Dubbo, благодаря удобному использованию, отличной производительности и хорошей стабильности.
Zookeeper имеет три режима работы: автономный режим, псевдорежим кластеров и кластерный режим.
- Автономный режим: этот режим вообще подходит для сред разработки и тестирования.С одной стороны у нас не так много машинных ресурсов, а с другой стороны обычная разработка и отладка не требуют отличной стабильности.
- Кластерный режим: Кластер ZooKeeper обычно состоит из группы машин.Как правило, более 3 машин могут формировать доступный кластер ZooKeeper. Каждая машина, входящая в состав кластера ZooKeeper, поддерживает текущее состояние сервера в памяти, и каждая машина взаимодействует друг с другом.
- Режим псевдокластера: это особый режим кластера, в котором все серверы кластера развернуты на одной машине. Когда у вас есть машина получше, развертывание в автономном режиме было бы пустой тратой ресурсов.В этом случае ZooKeeper позволяет запускать несколько экземпляров службы ZooKeeper на машине, запуская разные порты. услуга обеспечивается характеристиками кластера.
Знание ZooKeeper
Роли в Zookeeper
- Лидер: отвечает за инициирование и разрешение голосования, а также за обновление состояния системы.
- Фолловер (follower): для получения клиентского запроса и возврата результатов клиенту, в процессе голосования выбирается из основного
- Наблюдатель: может принимать клиентские подключения и пересылать запросы на запись ведущему, но наблюдатель не участвует в процессе голосования, только для расширения системы и повышения скорости чтения.
Модель данных Zookeeper
- Иерархическая структура каталогов, названная в соответствии с обычными соглашениями о файловой системе, аналогичная Linux.
- Каждый узел называется znode в zookeeper и имеет уникальный идентификатор пути.
- Узел Znode может содержать данные и дочерние узлы, но узел типа EPHEMERAL не может иметь дочерних узлов.
- Данные в Znode могут иметь несколько версий, такие как множество версий данных в пути, затем запрашивайте данные по этому пути, вам нужно принести версию.
- Клиентское приложение может быть предоставлено на узле монитора
- Узел поддерживает не частичное чтение и запись, а полное чтение и запись за один раз.
Особенности узла ZooKeeper
Узлы ZooKeeper имеют жизненный цикл, в зависимости от типа узла. В ZooKeeper узлы можно разделить на постоянные узлы (PERSISTENT) и временные узлы (EPHEMERAL) в зависимости от продолжительности, а также на последовательные узлы (SEQUENTIAL) и неупорядоченные узлы (по умолчанию неупорядоченные) в зависимости от того, упорядочены ли они.
После создания постоянного узла, если он не будет активно удален, он всегда будет сохранен в Zookeeper (он не исчезнет из-за аннулирования сеанса клиента, создавшего узел), временные узлы
Сценарии применения Zookeeper
ZooKeeper — это высокодоступная распределенная структура управления данными и координации системы. Основываясь на реализации алгоритма Paxos, фреймворк обеспечивает надежную согласованность данных в распределенной среде, и именно на этой функции ZooKeeper решает многие распределенные проблемы.
Стоит отметить, что ZooKeeper не предназначен для этих сценариев приложений по своей природе, но является типичным использованием, которое многие разработчики позже исследовали в соответствии с характеристиками его структуры и с использованием ряда интерфейсов API (или наборов примитивов), предоставляемых им. .
Публикация данных и подписка (центр конфигурации)
Модель публикации и подписки, так называемый центр конфигурации, как следует из названия, заключается в том, что издатель публикует данные на узле ZK, чтобы подписчик мог динамически получать данные, и осуществляет централизованное управление и динамическое обновление информации о конфигурации. Например, глобальная конфигурационная информация, список адресов сервисов сервисной инфраструктуры и т. д. очень удобны для использования.
Некоторая информация о конфигурации, используемая в приложении, размещается на ZK для централизованного управления. Такой сценарий обычно таков: приложение будет брать на себя инициативу получения конфигурации при запуске и в то же время регистрировать Watcher на узле, чтобы при каждом обновлении конфигурации в будущем оно уведомлять подписанного клиента в режиме реального времени.Всегда достигать цели получения последней информации о конфигурации. В службе распределенного поиска метаинформация индекса и состояние узла машины кластера серверов хранятся в некоторых назначенных узлах ZK для подписки каждого клиента.
Распределенная система сбора логов. Основная задача этой системы — собирать журналы, распределенные по разным машинам. Коллектор обычно выделяет модули задач сбора в соответствии с приложением, поэтому необходимо создать узел P с именем приложения в качестве пути на ZK, и прописать все IP-адреса машин этого приложения на узле P в виде дочерних узлы, так что при изменении машины сборщик может быть уведомлен в режиме реального времени, чтобы скорректировать распределение задач. Некоторую информацию в системе нужно получать динамически, и будут вопросы по ручной модификации этой информации вручную. Обычно предоставляется доступ к интерфейсу, например интерфейсу JMX, для получения некоторой информации о времени выполнения. После внедрения ЗК нет необходимости самостоятельно реализовывать комплекс решений, пока информация хранится на назначенном узле ЗК. Примечание. В сценариях приложений, упомянутых выше, используется предпосылка по умолчанию: объем данных невелик, но обновление данных может выполняться быстрее.
балансировки нагрузки
Балансировка нагрузки здесь - баланс мягкой нагрузки. В распределенной среде, чтобы обеспечить высокую доступность, оно обычно развертывает несколько копий и достигает службы сверстников. Потребители должны выбрать одну из этих одноранговых серверов для выполнения связанной бизнес-логики, которая обычно обычно является производителем, балансировкой потребительской нагрузки в промежуточном программе сообщений.
Служба имен
Службы именования также являются распространенным сценарием в распределенных системах. В распределенной системе с помощью службы имен клиентское приложение может получить адрес, поставщика и другую информацию о ресурсе или службе в соответствии с указанным именем. Именованным объектом обычно может быть машина в кластере, адрес предоставляемой услуги, удаленный объект и т. д. — все это мы можем вместе назвать именем (Name). Одним из наиболее распространенных является список адресов служб в некоторых распределенных инфраструктурах служб. Вызывая API для создания узлов, предоставленный ZK, легко создать глобально уникальный путь, который можно использовать в качестве имени.
Alibaba Group Open Selection Services Services Framework Dubbo использует Zookeeper в качестве своего обслуживания именования для поддержания списка глобальных сервисных адресов. В реализации Dubbo: поставщик услуг запускается, указанный узел на ZK/dubbo/${serviceName}/providersНапишите свой собственный URL-адрес в каталоге, и эта операция завершит выпуск службы. Когда потребитель услуг запустится, подпишитесь/dubbo/${serviceName}/providersURL-адрес поставщика в каталоге и отправить/dubbo/${serviceName} /consumersКаталог написать свой собственный адрес URL. Обратите внимание, что все зарегистрированные в адресах узла ZK являются временными, поэтому мы можем гарантировать поставщики услуг, и потребители могут автоматически смывать изменения в ресурсах.
Кроме того, Dubbo также имеет мониторинг зернальности услуг, и метод подписан./dubbo/${serviceName}Информация обо всех поставщиках и потребителях в каталоге.
Распределенное уведомление/координация
ZooKeeper имеет уникальный механизм регистрации наблюдателя и асинхронного уведомления, который может хорошо реализовать уведомление и координацию между различными системами в распределенной среде, а также реализовать обработку изменений данных в реальном времени. Способ использования обычно заключается в том, что разные системы регистрируют один и тот же знод на ЗК, следят за изменениями знода (включая содержимое самого знода и подузлов), и одна система обновляет зноду, тогда другая система может получать уведомление и сделать соответствующую сделку с.
Еще один механизм обнаружения сердцебиения: система обнаружения и обнаруженная система не связаны напрямую, а связаны с узлом на zk, что значительно снижает связанность системы. Другой режим системного планирования: система состоит из консоли и системы push.Консоль отвечает за управление системой push для выполнения соответствующей работы push. Некоторые операции, выполняемые администраторами в консоли, фактически изменяют состояние некоторых узлов на ZK, и ZK уведомляет клиента об изменениях в своем зарегистрированном клиенте Watcher, то есть системе push, а затем выполняет соответствующие push-задачи.
Другой режим отчета о работе: что-то похожее на систему распределения задач, после запуска подзадачи зайти в zk, чтобы зарегистрировать временную ноду, и регулярно отчитываться о ее ходе (записывать прогресс обратно на эту временную ноду), чтобы диспетчер задач мог Возможность узнать ход выполнения задачи в режиме реального времени.
Распределенная блокировка
Распределенная блокировка, что в основном связано с строгой согласованностью данных, которую нам гарантирует ZooKeeper. Службы блокировки можно разделить на две категории: одна предназначена для сохранения эксклюзивности, а другая — для контроля времени.
Так называемое сохранение монопольного доступа означает, что из всех клиентов, пытающихся получить блокировку, только один может в конце успешно получить блокировку. Обычной практикой является обращение с znode на zk как с замком черезcreate znodeспособ достижения. Все клиенты идут создавать/distribute_lockNode, успешно созданный клиент также владеет блокировкой. Управляющая последовательность клиента заключается в том, что все представления приобретают блокировку, которая в итоге будет устроена для выполнения, а есть только глобальная последовательность. Практика в основном аналогична вышеописанной, но здесь/distribute_lockуже существующий, клиент создает под ним временный упорядоченный узел (этим можно управлять через свойства узла:CreateMode.EPHEMERAL_SEQUENTIALуказать). Родительский узел Zk (/distribute_lock) поддерживает последовательность для обеспечения времени создания детских узлов, что формирует глобальное время каждого клиента.
- Свернувшись в том же узле узла NODE, не может быть одинаковым, пока создание Znode на узле, создать успешное шоу, которое успешно заблокировано. Знак слушателя, слушающий этот Znode, просто удалите этот Znode, чтобы уведомить другие клиенты, чтобы заблокировать.
- Создайте временный последовательный узел: создайте узел под узлом, создайте узел, поскольку оно является порядком, номер последовательности минимизируется, и когда блокировка выделяется, следующий серийный номер уведомлен.
Распределенная очередь
Что касается очередей, существует два вида очередей: одна — это обычная очередь «первым пришел — первым обслужен», а другая — ждать, пока члены очереди соберутся, прежде чем выполнять их по порядку. Для первого типа очередей базовый принцип сценария управления последовательностью в упомянутом выше сервисе распределенной блокировки одинаков, поэтому здесь я не буду вдаваться в подробности.
Второй вид очереди на самом деле является улучшением на основе очереди ФИФО. обычно можно найти в/queueПредустановленный под этот znode/queue/numNode и назначьте его n (или напрямую назначьте n /queue), указав размер очереди, а затем каждый раз, когда участник очереди присоединяется, он будет оценивать, достигнут ли размер очереди, и решать, может ли он начать исполнение. Типичный сценарий такого использования заключается в том, что в распределенной среде большая задача Задача А может быть выполнена только тогда, когда выполнено (или условно готово) множество подзадач. В это время, если одна из подзадач выполнена (готова), то переходим к/taskListСоздайте свой собственный узел временного времени (CreateMode.EPHEMERAL_SEQUENTIAL),когда/taskListЕсли вы обнаружите, что дочерние узлы ниже вас соответствуют указанному числу, вы можете перейти к следующему шагу и обработать их по порядку.
Используйте docker-compose для создания кластера
Выше мы представили очень много сценариев приложений для ZooKeeper, поэтому мы сначала узнаем, как построить кластер ZooKeeper, а затем реализуем приведенные выше сценарии приложений.
Структура каталогов файла выглядит следующим образом:
1├── docker-compose.yml
Напишите файл docker-compose.yml
docker-compose.ymlСодержимое файла следующее:
1version: '3.4'
2
3services:
4 zoo1:
5 image: zookeeper
6 restart: always
7 hostname: zoo1
8 ports:
9 - 2181:2181
10 environment:
11 ZOO_MY_ID: 1
12 ZOO_SERVERS: server.1=0.0.0.0:2888:3888;2181 server.2=zoo2:2888:3888;2181 server.3=zoo3:2888:3888;2181
13
14 zoo2:
15 image: zookeeper
16 restart: always
17 hostname: zoo2
18 ports:
19 - 2182:2181
20 environment:
21 ZOO_MY_ID: 2
22 ZOO_SERVERS: server.1=zoo1:2888:3888;2181 server.2=0.0.0.0:2888:3888;2181 server.3=zoo3:2888:3888;2181
23
24 zoo3:
25 image: zookeeper
26 restart: always
27 hostname: zoo3
28 ports:
29 - 2183:2181
30 environment:
31 ZOO_MY_ID: 3
32 ZOO_SERVERS: server.1=zoo1:2888:3888;2181 server.2=zoo2:2888:3888;2181 server.3=0.0.0.0:2888:3888;2181
В этом профиле Docker запускает три зеркалирования ZooKeeper, а локальные порты 2181, 2182 и 2183 привязаны к порту 2181 соответствующего контейнера соответственно.
ZOO_MY_IDиZOO_SERVERSдве переменные среды, необходимые для построения кластера Zookeeper.ZOO_MY_IDИдентификатор, идентифицирующий службу, целое число от 1 до 255, которое должно быть уникальным в кластере.ZOO_SERVERSэто список хостов в кластере.
существуетdocker-compose.ymlСледующий каталогdocker-compose up, можно посмотреть запущенный лог.
Подключиться к ZooKeeper
После запуска кластера мы можем подключиться к ZooKeeper для выполнения над ним операций, связанных с узлом.
- Сначала нам нужно скачать ZooKeeper.ZooKeeper Скачать.
- расстегнуть его
- в свой
confкаталог,zoo_sample .cfgизменить наzoo.cfg
Описание файла конфигурации
1# The number of milliseconds of each tick
2# tickTime：CS通信心跳数
3# Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。tickTime以毫秒为单位。
4tickTime=2000
5
6# The number of ticks that the initial
7# synchronization phase can take
8# initLimit：LF初始通信时限
9# 集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数（tickTime的数量）。
10initLimit=5
11
12# The number of ticks that can pass between
13# sending a request and getting an acknowledgement
14# syncLimit：LF同步通信时限
15# 集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数（tickTime的数量）。
16syncLimit=2
17
18# the directory where the snapshot is stored.
19# do not use /tmp for storage, /tmp here is just
20# example sakes.
21# dataDir：数据文件目录
22# Zookeeper保存数据的目录，默认情况下，Zookeeper将写数据的日志文件也保存在这个目录里。
23dataDir=/data/soft/zookeeper-3.4.12/data
24
25
26# dataLogDir：日志文件目录
27# Zookeeper保存日志文件的目录。
28dataLogDir=/data/soft/zookeeper-3.4.12/logs
29
30# the port at which the clients will connect
31# clientPort：客户端连接端口
32# 客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。
33clientPort=2181
34
35# the maximum number of client connections.
36# increase this if you need to handle more clients
37#maxClientCnxns=60
38#
39# Be sure to read the maintenance section of the
40# administrator guide before turning on autopurge.
41#
42# http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
43#
44# The number of snapshots to retain in dataDir
45#autopurge.snapRetainCount=3
46# Purge task interval in hours
47# Set to "0" to disable auto purge feature
48#autopurge.purgeInterval=1
49
50
51# 服务器名称与地址：集群信息（服务器编号，服务器地址，LF通信端口，选举端口）
52# 这个配置项的书写格式比较特殊，规则如下：
53
54# server.N=YYY:A:B
55
56# 其中N表示服务器编号，YYY表示服务器的IP地址，A为LF通信端口，表示该服务器与集群中的leader交换的信息的端口。B为选举端口，表示选举新leader时服务器间相互通信的端口（当leader挂掉时，其余服务器会相互通信，选择出新的leader）。一般来说，集群中每个服务器的A端口都是一样，每个服务器的B端口也是一样。但是当所采用的为伪集群时，IP地址都一样，只能时A端口和B端口不一样。
Вы не можете изменить zoo.cfg, конфигурация по умолчанию в порядке, затем выполните команду в разархивированном каталоге bin./zkCli.sh -server 127.0.0.1:2181подключить.
1Welcome to ZooKeeper!
22020-06-01 15:03:52,512 [myid:] - INFO [main-SendThread(localhost:2181):ClientCnxn$SendThread@1025] - Opening socket connection to server localhost/127.0.0.1:2181. Will not attempt to authenticate using SASL (unknown error)
3JLine support is enabled
42020-06-01 15:03:52,576 [myid:] - INFO [main-SendThread(localhost:2181):ClientCnxn$SendThread@879] - Socket connection established to localhost/127.0.0.1:2181, initiating session
52020-06-01 15:03:52,599 [myid:] - INFO [main-SendThread(localhost:2181):ClientCnxn$SendThread@1299] - Session establishment complete on server localhost/127.0.0.1:2181, sessionid = 0x100001140080000, negotiated timeout = 30000
6
7WATCHER::
8
9WatchedEvent state:SyncConnected type:None path:null
10[zk: 127.0.0.1:2181(CONNECTED) 0]
Далее мы можем использовать команду для просмотра узла.
-
Используйте команду ls, чтобы увидеть, что в данный момент содержится в ZooKeeper.
Заказ:
ls /1[zk: 127.0.0.1:2181(CONNECTED) 10] ls /
2[zookeeper] -
Создал новый znode "zk" и связанную с ним строку
Заказ:
create /zk myData1[zk: 127.0.0.1:2181(CONNECTED) 11] create /zk myData
2Created /zk
3[zk: 127.0.0.1:2181(CONNECTED) 12] ls /
4[zk, zookeeper]
5[zk: 127.0.0.1:2181(CONNECTED) 13] -
Получить узел znode
zkЗаказ:
get /zk1[zk: 127.0.0.1:2181(CONNECTED) 13] get /zk
2myData
3cZxid = 0x400000008
4ctime = Mon Jun 01 15:07:50 CST 2020
5mZxid = 0x400000008
6mtime = Mon Jun 01 15:07:50 CST 2020
7pZxid = 0x400000008
8cversion = 0
9dataVersion = 0
10aclVersion = 0
11ephemeralOwner = 0x0
12dataLength = 6
13numChildren = 0 -
удалить узел
zkЗаказ:
delete /zk1[zk: 127.0.0.1:2181(CONNECTED) 14] delete /zk
2[zk: 127.0.0.1:2181(CONNECTED) 15] ls /
3[zookeeper]
Из-за ограниченного места следующая статья будет реализована в коде один за другим в соответствии с упомянутыми выше сценариями приложения ZooKeeper.
Репозиторий файлов конфигурации ZooKeeper Docker
Репозиторий файлов конфигурации ZooKeeper Docker
Репозиторий файлов конфигурации ZooKeeper Docker
Вы можете вытащить проект прямо сверху, и для запуска RocketMQ потребуется всего два шага.
- отВытяните проект на GitHub
- Выполнить в папке ZooKeeper
docker-compose upЗаказ