Apache ZooKeeper. Блокировки в распределенных системах::Журнал СА 07-08.2016
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Контакты
   

  Опросы
1001 и 1 книга  
12.02.2021г.
Просмотров: 9655
Комментарии: 8
Коротко о корпусе. Как выбрать системный блок под конкретные задачи

 Читать далее...

11.02.2021г.
Просмотров: 10023
Комментарии: 12
Василий Севостьянов: «Как безболезненно перейти с одного продукта на другой»

 Читать далее...

20.12.2019г.
Просмотров: 17150
Комментарии: 1
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 15997
Комментарии: 13
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 16904
Комментарии: 6
Анализ вредоносных программ

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

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

Архив номеров / 2016 / Выпуск №07-08 (164-165) / Apache ZooKeeper. Блокировки в распределенных системах

Рубрика: Разработка /  Распределенные вычисления   | Дополнительные материалы

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

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

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

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

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

Рисунок 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

Рисунок 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.

Комментарии отсутствуют

Добавить комментарий

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

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru