Классическое распределенное чтение бумаги: Zookeeper

Эта статьяБумага ZooKeeperВ примечаниях к чтению ZooKeeper используется для координации процессов в распределенных системах и предоставления централизованных услуг, таких как отправка групп сообщений, общие регистры и распределенные блокировки для распределенных систем.

Услуги координации, необходимые в распределенных системах, включают в себя: настройку, членство в группах, выборы лидеров и услуги блокировки. ZooKeeper не предоставляет эти услуги напрямую, поскольку для реализации более слабых примитивов можно использовать более сильные примитивы. ZooKeeper предоставляет API-интерфейсы для разработчиков, чтобы они могли реализовать свои собственные примитивы. API ZooKeeper работает с объектами данных без ожидания в иерархии, подобной файловой системе, обеспечивая при этом целостность всех операций.Клиент первым пришел первым вышелисерийная запись. ZooKpeer использует конвейерную архитектуру для достижения высокой пропускной способности и низкой задержки, операции обновления используют Zab для обеспечения линейности, а операции чтения выполняются локально на сервере без необходимости определения порядка. Механизм наблюдения уведомляет клиента после обновления данных, чтобы клиент мог быстро получить последние данные.

Сервис ZooKeeper

ZooKeeper предоставляет клиентам API в виде библиотеки, которая также отвечает за подключение клиентов к серверам ZooKeeper. Узлы данных в ZooKeeper называютсяznode, организованный в пространстве имен дерева. Устанавливается после подключения клиента к серверубеседа, который отправляет запрос через дескриптор сеанса.

Обзор услуг

ZooKeeper предоставляет клиентам абстракцию (znode) объектов данных.

Есть два типа znodes:

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

Если установлено при создании файлаSEQUENTIALфлаг, то к имени файла добавляется автоматически увеличивающийся счетчик. ZooKeeper реализует механизм наблюдения, который может уведомить клиента после обновления объекта данных, и наблюдение будет запущено только один раз.

модель данных: Модель данных в ZooKeeper представляет собой файловую систему, которая поддерживает только полное чтение и запись.Znode хранит абстрактную концепцию приложения и используется для хранения конфигурации, метаданных и другой информации.

беседа: клиент устанавливает сеанс после подключения к ZooKeeper, и сеанс используется для идентификации клиента.

Клиентский API

create(path, data, flags): создать путь какpathзнод, будетdata[]сохранить в него, вернуть имя нового znode,flagsИспользуется для установки типа znode: нормальный или временный, а также для установкиSEQUENTIALлоготип.
delete(path, version): удалить, если версия совпадаетpathсоответствующий узел.
exists(path, watch):еслиpathЕсли соответствующий znode существует, верните true, иначе верните false.watchОтметьте, чтобы клиенты могли наблюдать за этим znode.
getData(path, watch): возвращает данные и метаданные, соответствующие znode,watchФункция аналогична.
setData(path, data, version): если версии совпадают, будетdata[]написатьpathв соответствующем зноде.
getChildren(path, watch): возвращает набор дочерних узлов znode.
sync(path): дождаться всех ожидающих обновлений,pathНе так много пользы.

Все вышеперечисленные методы предоставляют блокирующие и неблокирующие версии.Если входящий номер версии равен -1, проверка версии не выполняется.

ZooKeeper гарантирует

ZooKeeper имеет две основные гарантии порядка

Линейная запись: все обновления, изменяющие состояние ZooKeeper, являются последовательными;
Клиент первым пришел первым вышел: все запросы от клиентов выполняются в порядке поступления.

На примере можно продемонстрировать, как эти две гарантии гарантируют работу системы. Предположим, система выбирает главный узел для управления другими узлами, затем главному узлу необходимо обновить некоторую конфигурацию, а затем уведомить другие узлы, требуя:

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

может установитьreadyВ решении znode главный узел можно удалить перед настройкой и восстановить после завершения. когда другие узлы видятreadyЕсли вы не существуете, вы не читаете конфигурацию.

Но есть еще проблема: если другие узлы видятreadyПосле чтения конфигурации, но мастер-узел удаляет и начинает изменять конфигурацию, другие узлы получат устаревшую конфигурацию. Эту проблему можно решить с помощью механизма наблюдения,readyПосле удаления другие узлы будут своевременно уведомлены.

ZooKeeper имеет две гарантии долговечности:

Если большинство серверов активны, услуга доступна
Если ZooKeeper успешно отвечает на запрос модификации, модификация может сохраняться при бесконечном количестве сбоев, пока большинство узлов в конечном итоге могут восстановиться.

Примитивный пример

Управление конфигурацией: вам нужно только сохранить конфигурацию в znode, и каждый процесс может получать уведомления об обновлении конфигурации посредством наблюдения.
встретиться: Многие распределенные системы включают в себя главные узлы и рабочие узлы, но планирование узлов определяется планировщиком.Информация о главном узле может быть помещена в z-узел, чтобы рабочие узлы могли найти главный узел.
членство в группе: После того, как процесс члена группы проходит онлайн, соответствующий временный дочерний Znode может быть создан под Znode, соответствующий группе. После того, как процесс участника выходит, временный Znode также удаляется. Следовательно, статус члена группы может быть получен через ребенка Znode группы Znode.
Простой замок: Блокировка может создать соответствующую реализацию znode. Если создание прошло успешно, то получите блокировку. Если он уже существует, вам нужно дождаться освобождения блокировки (удаление znode) перед получением блокировки (созданием znode).
Простой замок без стада: будет большое количество процессов конкуренции за простые блокировки.После сортировки запросов блокировки, блокировки могут быть распределены по порядку.

Lock
1   n = create(l + “/lock-”, EPHEMERAL|SEQUENTIAL)
2   C = getChildren(l, false)
3   if n is lowest znode in C, exit
4   p = znode in C ordered just before n
5   if exists(p, true) wait for watch event
6   goto 2

Unlock
1   delete(n)

Блокировка чтения-записи: Блокировки записи аналогичны обычным блокировкам и являются взаимоисключающими с другими блокировками.

Write Lock
1   n = create(l + “/write-”, EPHEMERAL|SEQUENTIAL)
2   C = getChildren(l, false)
3   if n is lowest znode in C, exit
4   p = znode in C ordered just before n
5   if exists(p, true) wait for event
6   goto 2

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

Read Lock
1   n = create(l + “/read-”, EPHEMERAL|SEQUENTIAL)
2   C = getChildren(l, false)
3   if no write znodes lower than n in C, exit
4   p = write znode in C ordered just before n
5   if exists(p, true) wait for event
6   goto 3

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

Приложение ZooKeeper

Сервис разбора: в службе синтаксического анализа поисковой системы Yahoo главный узел должен информировать узел синтаксического анализа о конфигурации системы, а узел синтаксического анализа должен сообщать о своем собственном состоянии. Поэтому служба разрешения использует ZooKeeperУправление конфигурациейивыборы руководства. На рисунке ниже показаны операции чтения и записи в системе, и можно обнаружить, что операции чтения составляют большинство.

Katta: Katta — это распределенный индекс, главный узел назначает сегменты подчиненным узлам и отслеживает прогресс, в основном используя ZooKeeper для членства в группах.управление отношениями,выборы руководстваиУправление конфигурацией.
Сообщения Yahoo: брокер сообщений Yahoo отвечает за публикацию и получение сообщений в бесчисленных темах, эти темы распределены по нескольким серверам, и каждый сервер использует резервное копирование master-slave. Структура znode системы показана на рисунке ниже, аналогичноshutdown,migration_prohibitedИнформация о конфигурации системы,nodesсодержит информацию о серверах, входящих в группу, аtopicsСохраните мастер-сервер, который отвечает за конкретную тему, соответствующую подчиненному серверу.Кроме того, после сбоя мастер-узла его необходимовыборы руководства.

Реализация ZooKeeper

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

обработчик запросов

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

атомная трансляция

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

база данных с несколькими репликами

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

клиент-серверное взаимодействие

Когда сервер выполняет операцию записи, он уведомляет наблюдающего клиента и очищает наблюдение.Каждый сервер несет ответственность только за уведомление своих собственных подключенных клиентов. Каждый запрос на чтение соответствуетzxid, соответствующий идентификатору последней транзакции записи на сервере. Поскольку чтение выполняется локально на сервере, возможно, что некоторые записи перед чтением не синхронизируются с сервером, подключенным к клиенту.syncэксплуатация, гарантияsyncПоследующие операции чтения могут получитьsyncпредыдущий результат записи. Клиент получит последнюю версию с сервераzxid,zxidДругая функция заключается в том, чтобы после того, как клиент переключает сервер, новый сервер мог видеть, что представление не может быть позади представления, которое клиент видел раньше, то есть серверzxidне ранее чем у клиентаzxid. Если обнаружен сбой клиента, сеанс имеет период ожидания, и клиент также отправляет пульс при отсутствии активности, чтобы избежать тайм-аута.

использованная литература

Hunt, Patrick, et al. "ZooKeeper: Wait-free Coordination for Internet-scale Systems." USENIX annual technical conference. Vol. 8. No. 9. 2010.