Очередь сообщений (Message Queue)
Сообщения, наряду с блоками вычисления и хранения, составляют три основных блока почти в каждой блок-схеме системы. Очереди сообщений, по существу, являются связующим звеном между различными процессами в ваших приложениях и обеспечивают надежный и масштабируемый интерфейс взаимодействия с другими подключенными системами и устройствами.
О́чередь — структура данных с дисциплиной доступа к элементам «первый пришёл — первый вышел». Добавление элемента возможно лишь в конец очереди, выборка — только из начала очереди, при этом выбранный элемент из очереди удаляется.
Использование очереди сообщений
- Слабое связывание — очереди сообщений создают неявные интерфейсы обмена данными, которые позволяют процессам быть независимыми друг от друга т.е вы просто определяете формат сообщений отправляемых от одного процесса другому.
- Избыточность — Очереди позволяют избежать случаев неэкономного использования ресурсов процесса(например памяти) в результате хранения необработанной (лишней) информации.
- Масштабируемость — очереди сообщений позволяют распределить процессы обработки информации. Таким образом, они позволяют легко наращивать скорость, с которой сообщения добавляются в очередь и обрабатываются.
- Эластичность и возможность выдерживать пиковые нагрузки — очереди сообщений могут выполнять роль своего рода буфера для накопления данных в случае пиковой нагрузки, смягчая тем самым нагрузку на систему обработки информации и не допуская ее отказа.
- Отказоустойчивость — очереди сообщений позволяют отделить процессы друг от друга, так что если процесс, который обрабатывает сообщения из очереди падает, то сообщения могут быть добавлены в очередь на обработку позднее, когда система восстановится.
- Гарантированная доставка — использование очереди сообщений гарантирует, что сообщение будет доставлено и обработано в любом случае (пока есть хотя бы один обработчик).
- Гарантированный порядок доставки — большая часть систем очередей сообщений способны обеспечить гарантии того, что данные будут обрабатываться в определённом порядке (чаще всего в том порядке в котором они поступили).
- Буферизация — очереди сообщений позволяет отправлять и получать сообщения при этом работая с максимальной эффективностью, предлагая буферный слой — процесс записи в очередь может происходить настолько быстро, насколько быстро это в состоянии выполнить очередь сообщений, а не обработчик сообщения.
- Понимание потоков данных — очереди сообщений позволяют выявлять узкие места в потоках данных приложения, легко можно определить какая из очередей забивается, какая простаивает и определить что необходимо делать — добавлять новых обработчиков сообщений или оптимизировать текущую архитектуру.
- Асинхронная связь — очереди сообщений предоставляют возможность асинхронной обработки данных, которая позволяет поместить сообщение в очередь без обработки, позволяя системе обработать сообщение позднее, когда появится возможность.
- Обработку данных
- Буферизацию потоков данных
- Управление процессами
- Интеграцию и взаимодействие систем
Почему SaaS?
Добавление очереди сообщений для облачных приложений имеет смысл, только если есть чистый выигрыш в плане установки и эксплуатации. Добавление дополнительного архитектурного слоя отвечающего за очереди сообщений — непростая задача, особенно если вы решили использовать собственное решение или установить на свои сервера стороннее, так как это привнесёт дополнительные затраты на мониторинг, настройку, управление и повлияет на общую надёжность и безопасность системы.
Когда очереди сообщений легки в установке, просты в использовании, высоко доступны и чрезвычайно надёжны — все становиться гораздо проще.
Тут уместна аналогия получения энергии. Прогресс шёл от ветряных мельниц и угольных печей до промышленных электростанций и линий электропередач.Этот последний шаг — индустриализация энергии — изменило лик промышленности в мире. Это снизило затраты на строительство и производство, изменило города, заводы, и дома, и позволило создать новые изобретения, услуги и виды бизнеса.
Аналогичным образом, путём подключения служб очередей сообщений, разработчики больше не должны поддерживать огромный наборов сервисов, работающих на нескольких серверах и не опасаться простоя в результате отказа систем. В современном мире поставщики услуг берут на себя ответственность за управления серверами, API и другими ресурсами, а разработчик абстрагируясь от большинства физических ограничений может сконцентрироваться на реализации своей идеи.
Преимущества перехода на облачные очереди сообщений включают в себя:
- Увеличение скорости выхода на рынок: приложения и системы могут быть построены гораздо быстрее.
- Уменьшение сложности: снижение рисков и накладных расходов в стратегическом потенциале. Например вам сейчас кажется что свой собственный сервер с поднятым и сконфигурированным RabbitMQ кажется лучшим решением, то в долгосрочной перспективе при росте нагрузки, требованиях к HA(high availability) ранняя интеграция сторонних сервисов может сыграть свою положительную роль.
- Увеличение масштабируемости: возможность легко масштабировать производительность и функциональность
С чего начать?
- Amazon SQS
- IronMQ
- StormMQ
- Windows Azure Queues
PS Я надеюсь мне удалось заронить каплю сомнения в выбор «поставить свой сервер MQ или использовать сторонний сервис» и заинтересовать в существующих SaaS решениях в области очередей сообщений.
upd: добавил Windows Azure Queues
Очереди сообщений
Очередь сообщений – это форма асинхронного обмена информацией между сервисами, применяемая в бессерверных и микросервисных архитектурах. Сообщения хранятся в очереди, пока не будут обработаны и удалены. Каждое сообщение обрабатывается только один раз и только одним потребителем. Очереди сообщений могут использоваться для разделения сложных процессов обработки, для буферизации или организации пакетной обработки, а также для сглаживания пиковых нагрузок.
Ниже приведены несколько ресурсов, которые помогут вам лучше понять очереди сообщений в целом. Чтобы узнать об очередях сообщений в AWS, посетите веб-сайт Простого сервиса очередей Amazon (SQS).
![]()
Основные сведения об очередях сообщений
В современной облачной архитектуре приложения разделяют на небольшие независимые элементы, которые проще разрабатывать, развертывать и обслуживать. Очереди сообщений обеспечивают для таких распределенных приложений возможность взаимодействия и координации. Очереди сообщений могут значительно упростить написание кода приложений с разделенными компонентами, а также повысить их производительность, надежность и масштабируемость.
С помощью очередей сообщений различные части системы могут обмениваться информацией и обрабатывать операции асинхронно. Очередь сообщений состоит из простого буфера, в котором временно хранятся сообщения, и адресов, позволяющих программным компонентам подключаться к очереди для отправки и получения сообщений. Сообщения обычно небольшие и могут представлять собой запросы, ответы, сообщения об ошибках или просто информацию. Чтобы отправить сообщение, компонент, называемый источником, добавляет сообщение в очередь. Сообщение хранится в очереди до тех пор, пока другой компонент, называемый получателем, не получит сообщение и не сделает с ним что-то.

Многие источники и получатели могут использовать одну очередь, но каждое сообщение обрабатывается одним получателем только один раз. Поэтому такой шаблон обмена сообщениями часто называют обменом информацией «один к одному» или «точка-точка». Когда сообщение должно обрабатываться несколькими получателями, очереди сообщений можно сочетать с моделью отправки сообщений «издатель-подписчик» в шаблоне проектирования распространения. Дополнительные сведения об обмене сообщениями «издатель-подписчик» на AWS приведены в разделе Что такое обмен сообщениями «издатель-подписчик»? и на веб-сайте Простого сервиса уведомлений Amazon (SNS).
Что такое mq очередь
Класс MQ (полное имя ru.cinimex.stub.utils.MQ) содержит методы записи и чтения сообщений из MQ-очередей IBM® WebSphere.
Класс был разработан для обеспечения одной из возможности взаимодействия (обмена) между тестом и заглушками.
| Тип возвращаемого значения | Метод | Описание метода | Описание параметров |
|---|---|---|---|
| void | MQ(String prefix) | Конструктор класса | prefix — префикс параметров подключения к менеджеру очередей в файле extra.settings |
| String | readRfh2Message(String queue, boolean delete) | Чтение сообщения из очереди | queue — имя очереди; delete — удалять ли сообщение из очереди |
| String | readRfh2Message(String queue, Map matchMap, boolean delete) | Чтение сообщения из очереди с фильтровкой сообщений на сервере по заданной мапе со значениями MQMD-заголовков | queue — имя очереди; matchMap — мапа со значениями MQMD-заголовков, по которым на сервере будет искаться сообщение. Допускается задавать следующие заголовки: «messageId», «correlationId» «groupId», «messageSequenceNumber», «offset» и «accountingToken» delete — удалять ли сообщение из очереди |
| Map | getMQMDHeaders() | Получение мапы mqmd-заголовков. Метод может быть вызван только после вызова метода readRfh2Message. После выполнения метода внутренняя структура объекта MQ, хранящая mqmd-заголовки, очищается | |
| Map | getRfh2Headers() | Получение мапы пользовательских rfh2-заголовков. Метод может быть вызван только после вызова метода readRfh2Message. После выполнения метода внутренняя структура объекта MQ, хранящая rfh2-заголовки, очищается | |
| void | sendRfh2Message(String queue, String message) | Запись сообщения в очередь | queue — имя очереди; message — строка с сообщением |
| void | setMQMDHeaders(Map headers) | Установить mqmd-заголовки во внутренней структуре объекта MQ, хранящей mqmd-заголовки | headers — мапа с устанавливаемыми mqmd-заголовками |
| void | addMQMDHeader(String header, Object value) | Добавить mqmd-заголовок во внутреннюю структуру объекта MQ, хранящую mqmd-заголовки | header — имя mqmd-заголовка; value — значение mqmd-заголовка |
| void | setRfh2Headers(Map headers) | Установить rfh2-заголовки во внутренней структуре объекта MQ, хранящей rfh2-заголовки | headers — мапа с устанавливаемыми rfh2-заголовками |
| void | addRfh2Header(String header, Object value) | Добавить rfh2-заголовок во внутреннюю структуру объекта MQ, хранящую пользовательские rfh2-заголовки | header — имя rfh2-заголовка; value — значение rfh2-заголовка |
| void | clearQueueGet(String queue) | Очистка очереди | queue — имя очереди |
| int | getCurrentQueueDepth(String queue) | Получение глубины очереди | queue — имя очереди |
| void | sendMessage(String queue, byte[] bytes) | Запись в очередь сообщения в виде массива байт. Внимание. Метод не устанавливает (не записывает) никаких заголовков | queue — имя очереди; bytes — записываемый массив байт |
| byte[] | readByteMessage(String queue, boolean delete) | Чтение из очереди сообщения в виде массива байт. Внимание. Метод не читает (не запоминает) никаких заголовков | queue — имя очереди; delete — удалять ли сообщение из очереди |
- или явно в атрибуте varsMap действий старта заглушки RunStub и RunStubs;
- или, если атрибут varsMap не был задан, то неявно из значения переменной $extra.settings$ теста (см. Ограничения на имена переменных и файлов).
Если же заглушка запускается автономно (т.е. не из теста), то необходимо параметры файла настроек загрузить в groovy-скрипте до использования методов класса SOAP следующим образом:
Service.loadProjectExtraSettings(new File(projectDirectory.getCanonicalPath()),
«Results/extra.settings»);
В данном примере файл настроек находится по относительному пути Results/extra.settings.
Важно в первом параметре метода loadProjectExtraSettings задать именно каталог проекта, а не производную от него,
поскольку с ним связываются параметры файла настроек не только при их загрузке, но и выгрузке после завершения работы.
- hostName — доменное имя или IP-адрес компьютера, на котором расположен менеджер очередей;
- port — порт менеджера очередей;
- queueManagerName — имя менеджера очередей;
- channelName — имя канала, который используется менеджером очередей;
- mquser — имя пользователя. Необязательный параметр;
- mqpassword — пароль пользователя. Необязательный параметр.
Пример фрагмента задания параметров подключения к менеджеру MQ-очередей IBM® WebSphere в файле настроек:
# MQ
ctt.hostName=mq_pc.vm.cmx.ru
ctt.port=1415
ctt.queueManagerName=BRK01
ctt.channelName=SYSTEM.ADMIN.SVRCONN
ctt.mquser=mqbrkr
ctt.mqpassword=mqbrkr
Пример вызова метода чтения очереди в режиме browse в groovy-скрипте заглушки:
MQ tmq = new MQ(«ctt»);
String queueName = «TEST_QUEUE»;
String msg = tmq.readRfh2Message(queueName, false); // read & leave
log.info(«*** MQ msg: » + msg);
MQMD-заголовки, по значениям которых можно выполнять поиск сообщений на сервере:
| Имя заголовка | Тип | Длина | Примечание |
|---|---|---|---|
| messageId | java.lang.byte[] | 24 | Идентификатор сообщения, устанавливается самим MQ |
| correlationId | java.lang.byte[] | 24 | Приложение-получатель может искать сообщение по этому заголовку средствами MQ |
| groupId | java.lang.byte[] | 24 | Используется для группировки сообщений |
| messageSequenceNumber | java.lang.Integer | Номер сообщения в логической группе | |
| offset | java.lang.Integer | ||
| accountingToken | java.lang.byte[] | 32 |
Использование методов класса MQ в тесте
Можно вызывать методы класса MQ в groovy-действиях теста GroovyScript и GroovyInline.
При этом нужно помнить, что имя файла настроек нужно обязательно задать в файле глобальных настроек действием PutVariable в переменной $extra.settings$.
В таком случае в самом конце выполнения файла глобальных настроек будут автоматически загружены параметры из файла настроек и, соответственно, станет возможным использование методов класса MQ.
Что такое MQ? Основные понятия
Что такое MQ? MQ — очередь сообщений, которая позволяет приложениям общаться, отправляя сообщения друг другу, и обеспечивает временное хранилище данных, когда целевая программа занята или не подключена.
Messages queue: базовые понятия
Очередь — это линия вещей, ожидающих обработки в порядке очередности, начиная с начала строки. Представляет собой очередь сообщений, отправляемых между приложениями. Включает последовательность рабочих объектов, которые ждут обработки.
Сообщение — это данные, передаваемые между отправителем и приложением-получателем. Что такое MQ на деле? Примером сообщения может быть то, что говорит системе о начале обработки задачи, и может содержать информацию о завершенной задаче.

Очередь сообщений
Базовая архитектура очереди сообщений проста: есть клиентские приложения, называемые производителями, которые создают сообщения и доставляют их в очередь. Другое приложение, называемое потребителем, подключается и обрабатывает сообщения. Уведомления, помещенные в очередь, сохраняются до тех пор, пока потребитель не получит их.
Messages queue обеспечивает асинхронный протокол связи. Система, которая помещает сообщение в очередь, не требует немедленного ответа на продолжающуюся обработку.
Что такое MQ на примере почтовых сообщений? Email — лучший пример асинхронного обмена сообщениями. Когда отправляется электронное письмо, отправитель может продолжить обработку других данных без немедленного ответа от получателя. Этот способ обработки сообщений отделяет производителя от потребителя: корреспондентам не нужно одновременно взаимодействовать с очередью сообщений.
Что такое MQ? Технологии обработки
Развязка используется для описания количества фрагментов системы, которые зависят от других компонентов. Развязка — это процесс их разделения с целью более замкнутой функциональности. Система считается развязанной, когда два или более компонента могут взаимодействовать без подключения. Она может оставаться полностью автономной. Развязка часто является признаком хорошо структурированной компьютерной системы.
Если один процесс в развязанной системе не обрабатывает сообщения из очереди, другие сообщения могут быть добавлены в очередь и обрабатываться, пока система не восстановится.

Пример очереди сообщений
Вместо того чтобы создавать одно большое приложение, можно разделить разные части его и поддерживать связь между ними асинхронно при помощи сообщений. Таким образом, различные части приложения могут развиваться самостоятельно, быть написаны на разных языках или поддерживаться отдельными группами разработчиков.
Что такое MQ? Это очередь сообщений, которая поддерживает процессы в приложении отдельно и независимо друг от друга. Первому процессу никогда не потребуется ссылаться на другой процесс или отправлять уведомления другому компоненту. Он может просто поместить сообщение в очередь, а затем продолжить обработку. Другие процессы также могут осуществлять свою работу независимо. Такой способ обработки сообщений создает систему, которую легко поддерживать и легко масштабировать.
