Очереди. Теория и практика. Часть 3. Сервер очередей

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

Очереди. Теория и практика
Часть 3. Сервер очередей

В предыдущих статьях [1, 2] мы рассматривали использование очередей в рамках одного процесса и АПИ ZeroMQ между разными компонентами напрямую. Однако для разработки более сложных систем есть специализированные службы middleware, через которые проходят сообщения

Такие службы называются брокерами сообщений или серверами очередей:

• Очередь – это структура данных, которая соответствует принципу: первый пришел – первый вышел.
• Сервер очередей – это отдельный процесс или служба, которая принимает сообщения от производителей (Producer) и распределяет их между потребителями (Consumer) сообщений.

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

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

Рисунок 1. Взаимодействие разных систем в реализации фотохостинга

Загрузка и форматирование фото- и особенно видеоконтента – это процесс, который потребляет много ресурсов: памяти и процессорного времени. А в некоторых случаях, например, нам необходимо выделить лицо человека на фотографии. А это точно не сделать в режиме онлайн средствами PHP или Python.

Поэтому в системах с большим числом посещений все организовано похожим образом: загрузка видео осуществляется на отдельный «сервер загрузки» [1]. По окончании загрузки сервер передает информацию в виде сообщения на «сервер очередей» [2]. Служба обработки фотовидеоконтента [3] постоянно опрашивает сервер очередей, и, как только там появляется информация о новом загрузочном материале, на «графическом сервере» запускается скрипт перевода в нужный формат или иной обработки. Этот скрипт берет файл по указанному в сообщении адресу, конвертирует его, и сформированный новый контент загружается на веб-сервер раздачи [4] «статического контента».

Необходимо отметить, что в системах с большим числом посещений, серверов «загрузки контента», «конвертирования» и «серверов раздачи статики» может быть столько, сколько необходимо для бесперебойной работы. Центральное место в такой системе занимает сервер очередей.

Использование серверов очередей имеет два основных паттерна:

• синхронная передача сообщений, когда потребитель сообщения получает сообщение немедленно. Еще такой паттерн называют «Подписка»;
• асинхронная обработка сообщений, когда потребитель сообщения запрашивает сообщения, когда ему удобно.

Redis как сервер очередей

Redis представляет собой продвинутое key/value-хранилище, которое использует несколько разных типов данных. Нас в данной статье будут интересовать из них два типа: «Списки» и «Подписки».

Возвращаясь к части 1 данного цикла [1], вспомним, что очередь можно реализовать, как двунаправленный список. Если мы хотим положить сообщение в очередь, мы вставляем в начало списка некоторый элемент, и, наоборот, если мы хотим изъять сообщение из очереди, то должны извлечь элемент из хвоста очереди. Для работы со списками есть команды:

• POPL/POPR – изъять элемент с начала/конца списка;
• PUSHL/PUSHR – положить элемент в начало/конец списка.

В качестве сообщения, как правило, удобно передавать текстовое сообщение в формате JSON.

Статью целиком читайте в журнале «Системный администратор», №7-8 за 2014 г. на страницах 84-89.

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

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