Apache ZooKeeper. Блокировки в распределенных системах

 АЛЕКСАНДР КАЛЕНДАРЕВ, AD1 , программист, akalend@mail.ru

Apache ZooKeeper
Блокировки в распределенных системах

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

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

Особенность такой системы в том, что данные из финансовой системы поступают с некоторой сетевой задержкой, и в то время, когда выполняется запрос от клиента А, может прийти точно такой же запрос от клиента В, который еще непоступил в кэш (см. рис. 1). И в нашей системе по логике, раз нет данных в кэше, то придется повторить такой же запрос, который нам может стоить денег. Чтоб этого не произошло, необходимо как-то уведомить нашу систему, не повторять запрос, пока такой же запрос выполняется. Если система распределенная, то это должно быть какое-то централизованное устройство. Таким устройством и выступает сервер блокировок.

Рисунок 1. Обработка запроса

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

Введение в Apache ZooKeeper

В качестве сервера блокировок рассмотрим проект Apache ZooKeeper [1], который был изначально разработан компанией Yahoo как субпроект Hadoop. Что он собой представляет? Это иерархическое хранилище, в основу которого положена концепция, аналогичная файловой системе, доступ к узлам по пути. Такой узел называется znode (очевидно, сокращение от Zookeeper Node). Каждая znode может содержать данные и дочерние узлы. Существует корневая znode, от которой происходит ветвление других узлов.

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

• Последовательную консистентность – изменение данных от разных клиентов обрабатывается в соответствии с очередностью их поступления.
• Атомарность – изменение данных происходит в один момент времени только от одного клиента.
• Единый образ данных – клиент будет иметь доступ к одним и тем же данным, вне зависимости от сервера, к которому он подключен.
• Надежность – после обновления данных оно будет доступно с того времени, когда оно произошло.

Главная особенность ZooKeeper в том, что он в отличие от других систем хранения поддерживает концепцию обработчиков событий: watches. Каждый клиент может установить обработчик на события в любой znode (в соответствии сограничениями ACL, но это тема отдельной статьи): удаление, добавление или изменение данных дочерних элементов. Когда наступает событие, клиент получает уведомление о том, что znode была изменена. Если соединение между клиентом и сервером было разорвано, то клиент также получает локальное уведомление. Механизм уведомлений реализуется на клиентской стороне.

На рис. 2 представлена схема двух дочерних узлов n-1 и n-2 узла con. Тогда путь до узла n-1 будет /con/n-1, а узла n-2 – /con/n-2. Для доступа к данным znode используются основные команды API:

• getData – извлечение данных из znode;
• setData – запись данных в znode;
• getChildren – получение списка дочерних узлов;
• create – создание дочернего узла;
• delete – удаление дочернего узла;
• exists – проверка наличия узла;
• sync – ожидание, пока данные не изменятся (data to be propagated).

Существует два вида узлов:

• персистентные (постоянные);
• эфимерные, временные, которые существуют только в период пользовательской сессии.

Также узел может иметь свойство последовательности. Это аналогично автоинкрементному полю в MySQL. Нами задается префикс, например «n-», а далее при создании нового узла у него будет меняться суффикс, с увеличением наединицу, который представляет 16-битное целое число: 00000001, 00000002...

Рисунок 2. Представление znode

Статью целиком читайте в журнале «Системный администратор», №07-08 за 2016 г. на страницах 92-95.

PDF-версию данного номера можно приобрести в нашем магазине.

1. Сайт проекта ZooKeeper – https://zookeeper.apache.org.
2. Клиентский PHP-модуль ZooKeeper – https://pecl.php.net/package/zookeeper.
3. Клиентский Python-модуль ZooKeeper – https://kazoo.readthedocs.io/en/latest.

Комментарии могут оставлять только зарегистрированные пользователи