 |
|
|
|
Очереди. Теория и практика. Часть 3. Сервер очередей
Очереди. Теория и практика В предыдущих статьях [1, 2] мы рассматривали использование очередей в рамках одного процесса и АПИ ZeroMQ между разными компонентами напрямую. Однако для разработки более сложных систем есть специализированные службы middleware, через которые проходят сообщения Такие службы называются брокерами сообщений или серверами очередей:
В качестве производителей и потребителей сообщений могут быть разные процессы и службы. В статье мы с ами рассмотрим разные паттерны использования серверов очередей. Пример использования очереди. Пусть мы хотим организовать видео- или фотохостинг (см. рис. 1). У нас есть кластер веб-серверов, который отдает статический контент.
Рисунок 1. Взаимодействие разных систем в реализации фотохостинга Загрузка и форматирование фото- и особенно видеоконтента – это процесс, который потребляет много ресурсов: памяти и процессорного времени. А в некоторых случаях, например, нам необходимо выделить лицо человека на фотографии. А это точно не сделать в режиме онлайн средствами PHP или Python. Поэтому в системах с большим числом посещений все организовано похожим образом: загрузка видео осуществляется на отдельный «сервер загрузки» [1]. По окончании загрузки сервер передает информацию в виде сообщения на «сервер очередей» [2]. Служба обработки фотовидеоконтента [3] постоянно опрашивает сервер очередей, и, как только там появляется информация о новом загрузочном материале, на «графическом сервере» запускается скрипт перевода в нужный формат или иной обработки. Этот скрипт берет файл по указанному в сообщении адресу, конвертирует его, и сформированный новый контент загружается на веб-сервер раздачи [4] «статического контента». Необходимо отметить, что в системах с большим числом посещений, серверов «загрузки контента», «конвертирования» и «серверов раздачи статики» может быть столько, сколько необходимо для бесперебойной работы. Центральное место в такой системе занимает сервер очередей. Использование серверов очередей имеет два основных паттерна:
Redis как сервер очередей Redis представляет собой продвинутое key/value-хранилище, которое использует несколько разных типов данных. Нас в данной статье будут интересовать из них два типа: «Списки» и «Подписки». Возвращаясь к части 1 данного цикла [1], вспомним, что очередь можно реализовать, как двунаправленный список. Если мы хотим положить сообщение в очередь, мы вставляем в начало списка некоторый элемент, и, наоборот, если мы хотим изъять сообщение из очереди, то должны извлечь элемент из хвоста очереди. Для работы со списками есть команды:
В качестве сообщения, как правило, удобно передавать текстовое сообщение в формате JSON. Статью целиком читайте в журнале «Системный администратор», №7-8 за 2014 г. на страницах 84-89. PDF-версию данного номера можно приобрести в нашем магазине. |
АЛЕКСАНДР КАЛЕНДАРЕВ, РБК Медиа, программист, 
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
