Что такое mq очередь

Очереди сообщений

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

Работа с очередями сообщений доступна только в редакции ELMA Enterprise .

В ELMA4 можно работать со следующими типами очередей:

• RabbitMQ — платформа, которая реализует обмен сообщениями между компонентами программной системы на основе стандарта AMQP (Advanced Message Queuing Protocol) и выпускается под Mozilla Public License;
• MSMQ (Microsoft Message Queuing Services) — стандарт очереди сообщений, входящий в стандартную поставку Microsoft Windows;
• JMS (Java Message Service) — протокол обмена сообщениями между приложениями, содержащий Java API. Позволяет приложениям создавать, отправлять, получать и читать сообщения. Для работы используется сервер WebLogic JMS.

Работа с очередями сообщений осуществляется в дизайнере в разделе Очереди сообщений .

Все настроенные очереди отображаются в таблице.

Чтобы добавить новую очередь сообщений, нажмите кнопку + Очередь и заполните поля. В настройках нужно указать название и выбрать тип очереди (RabbitMQ, MSMQ или JMS). Набор полей для заполнения зависит от типа очереди.

Если вы хотите изменить настройки, нажмите на название очереди в таблице.

Чтобы удалить очередь, нажмите .

Настройки очереди сообщений типа RabbitMQ

Для корректной настройки и работы очереди сообщений типа RabbitMQ должен быть установлен и доступен сервер RabbitMQ. Подробнее об этом читайте статью в Базе знаний.

Ниже на рисунке представлены настройки очереди.

Хост * — IP-адрес или наименование сервера RabbitMQ, к которому вы подключаетесь (например, localhost).

Порт — порт подключения к серверу. По умолчанию используется порт 5672.

Виртуальный хост * — хост, указанный в настройках сервера RabbitMQ. По умолчанию рекомендуется использовать «/».

Имя точки доступа * — имя точки доступа, которое указано в настройках сервера RabbitMQ на вкладке Exchanges .

Имя очереди * — имя очереди, которое указано в настройках сервера RabbitMQ на вкладке Queues .

Логин * — логин пользователя для подключения к серверу RabbitMQ.

Пароль * — пароль пользователя для подключения к серверу RabbitMQ.

Тайм-аут — время ожидания получения сообщения по очереди (в секундах). По умолчанию — 10 секунд.

Чтобы обеспечить безопасность при обмене сообщениями, можно использовать TLS-соединение. Для этого установите флажок Включить и заполните поля в блоке Настройки TLS .

Пароль для клиентского сертификата — указание пароля клиентского сертификата.

Имя сервера — имя сервера RabbitMQ, которое должно соответствовать записям SAN (Subject Alternative Name) или CN (Common Name) сертификата сервера.

Путь до клиентского сертификата — путь до клиентского сертификата, который используется для проверки на стороне клиента. Сертификат имеет формат PKCS12.

По умолчанию включена опция Клиентская верификация сертификата . Не рекомендуется выключать ее в продуктивных средах.

Настройки очереди сообщений типа MSMQ

Очереди сообщений типа MSMQ могут быть общие и частные. Подробнее об этом можно прочитать в статье в Базе знаний.

Ниже на рисунке представлены настройки очереди.

Строка подключения * — строка подключения, в которой задаются основные параметры подключения (протокол, имя сервера, к которому нужно подключиться, тип очереди, имя очереди). Вы можете ознакомиться с особенностями указания строки подключения, нажав :

• подключение к очереди производится от имени пользователя Windows, под которым работает сервер ELMA4;
• доступ к очередям регулируется сервером очередей сообщений.

Варианты строки подключения:

• .\private$\local_name_queue — подключение к частной очереди на локальном компьютере;
• FormatName:DIRECT=OS:server01\QueueName — прямое имя общей очереди на компьютере server01;
• FormatName:DIRECT=OS:ws02\private$\QueueName — прямое имя частной очереди на компьютере ws02.

Настройки очереди сообщений типа JMS

Для корректной настройки и работы очереди сообщений типа JMS должен быть установлен сервер JMS.

Ниже на рисунке представлены настройки очереди.

Адрес и порт * — адрес и порт сервера сообщений JMS в формате t3://localhost: , где:

• localhost — адрес сервера JMS;
• адрес порта — номер порта сервера JMS.

Имя очереди * — имя очереди, указанное в настройках сервера JMS.

ConnectionFactory * — объект на сервере сообщений, инкапсулирующий ряд параметров конфигурации соединения, который определяется администратором сервера. Предназначен для создания соединения с провайдером JMS.

Логин * — логин пользователя для подключения к очереди сообщений.

Пароль * — пароль пользователя для подключения к очереди сообщений.

Проверка

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

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

Нашли опечатку? Выделите текст, нажмите ctrl + enter и оповестите нас

Очередь сообщений (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).

Очереди сообщений

При работе с большими системами, которые состоят из множества компонентов, возникает вопрос: «Как интегрировать несколько приложений для работы друг с другом?». Для этого нужен надёжный, асинхронный и быстрый способ передачи данных, который также позволит передавать информацию в разных форматах.

Все эти свойства есть в системе обмена сообщениями. Они полезны когда:

• Нужно отправить данные из точки А в точку Б.
• Нужно интегрировать несколько систем.
• Нужно масштабирование.
• Нужна возможность мониторить потоки данных.
• Нужна асинхронная обработка.
• Нужна буферизация.

Концепт обмена сообщениями

Обмен сообщениями неновое изобретение. Он активно используется внутри операционной системы для обмена информацией между несколькими процессами (inter-process communication) и для обмена между несколькими потоками внутри процесса (inter-thread communication).

Самый простой способ представить очередь сообщений как длинную трубу в которую можно помещать шарики. Мы можем написать сообщение на шаре и закинуть его в трубу и кто-то получит его на другой стороне. Из такой концепции можно понять несколько вещей.

• Отправитель не имеет представления о том кто именно примет сообщение.
• Отправитель не переживает о том когда его сообщение будет получено.
• Отправитель может засовывать сколько угодно сообщений с удобной ему скорость.
• Это не повлияет на получателя, ведь он сам решает сколько сообщений ему удобно доставать.
• Ни отправитель, ни получатель не знают об устройстве друг друга.
• Ни отправитель, ни получатель не переживают про нагрузку и вместительность друг друга.
• Также они не знаю о том где каждый из них находиться. Они могут быть в одной комнате, в разных комнатах или зданиях.

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

Также очереди работают по модели «издатель-подписчик». В ней издатель оправляет сообщение в очередь, а подписчик смотрит в очередь и извлекает интересные ему сообщения, после чего занимается их обработкой. Благодаря этой концепции, осуществляется асинхронная коммуникация.

Причины использовать очереди сообщений

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

Масштабирование
Очереди распределяют процессы обработки информации. Это дает возможность гибко реагировать на нагрузку и добавлять или убирать дополнительные обработчики.

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

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

Decoupling and coupling
С помощью очередей можно достичь двух противоположных целей.

• Decoupling. Если у нас большой монолит, то будет сложно интегрировать новые фичи. В таком случае очередь сообщений позволяет разъединить одно приложения на несколько независимых компонентов и настроить коммуникацию между ними.
• Coupling. Иногда нужно, чтобы несколько систем работали как одно целое, очередь позволяют создать промежуточный слой для коммуникации между разными элементами системы.

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

Гарантированная доставка

Гарантированная доставка является одной из ключевых характеристик системы обмена сообщений. Всего есть три типа доставки:

• at least once
• at most once
• exactly once

At least once
Самый простой способ доставки при котором обработчик получает одно и то же сообщение до тех пор, пока не удалит его из очереди или не подтвердит получение. Это значит что возможны ситуации, когда приложение обрабатывает одно сообщение несколько раз.

Такая особенность подразумевает, что обработчик будет корректно работать в случае дублирования сообщений. А такое может случаться часто. Например, упала сеть в момент, когда приложение подтверждало получение — оно получит его ещё раз.

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

С другой стороны, такой подход гарантирует 100% получение сообщения. Даже если получатель сообщения упадёт, до того как подтвердит обработку, то он просто ещё раз его обработает после перезапуска.

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

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

Exactly Once
Идеальный сценарий работы очереди, но проблема в том что его нереально воплотить в жизнь из-за множества проблема, которые сами по себе решить сложно, не говоря уже об их совокупности.

Все они происходят из двух утверждений:

• Отправители и получатели не идеальны
• Сеть не идеальна.

Что порождает такие проблемы как:

• Отправитель может забыть отправить сообщение
• Сеть между отправителем и очередью может упасть
• Сеть между очередью и получателем может упасть
• База данных самой очереди может не сохранить сообщение
• Подтверждение что сообщение обработано может не дойти до очереди и отправителя

Именно поэтому очень сложно гарантировать одноразовую доставку сообщения. Намного проще сделать систему устойчивой к дубликатам сообщений и использовать подход at-least-once.

Компоненты очереди сообщений

Система обмена сообщениями состоит из нескольких компонентов, которые позволяют ей нормально функционировать и выполнять свои задачи.

Сообщения — любые данные, которые нужно передать через очередь конвертируются в сообщение, которые состоят из двух частей:

• Заголовки (headers) — в них расположена служебная информация, которая используется самой очередью для правильной обработки сообщения.
• Тело (body) — информация, которую мы передаем с помощью очереди.

Каналы (channels) — логические соединения между приложениями и системой очередей, которые предоставляют изолированную коммуникацию. Каналы позволяют передавать сообщение в одном из двух режимов:

• point-to-point — протокол, который обеспечивает прямую коммуникацию между двумя приложениями.
• publish-subscribe — протокол, в котором отправитель сообщения не знает конкретного получателя, а просто отправляет сообщение в очередь, на которую могут быть подписаны потребители.

Маршрутизатор (router) — помещает сообщения из каналов по разным очередям используя ключ маршрутизации из заголовков сообщения.

Очередь (queue) — хранилище для наших сообщений, которое может находиться как в оперативной памяти так и на диске.

Виды очередей

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

broadcast (fanout) exchange
В таком случае отправляется копия сообщения во все доступные очереди, ключ маршрутизации игнорируется.

direct exchange
Все сообщения имеют свой ключ маршрутизации, который определяет в какую очередь нужно положить сообщение. В дальнейшем сообщения будут переданы по принципу Round Robin подписанным обработчикам. Это значит что только один обработчик получит сообщение.

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

Обычно ключи маршрутизации стараются делать в иерархическом виде. Это достигается за счет разделения логических частей (слов) точками. Например вот так:

[region].[availability-zone].[service].[instance] eu-east.az1.computer.homepc

Сами же паттерны создаются с использованием специальных символов:

• * — заменитель только для одного слова.
• # — заменитель для нескольких слов

Что позволяет сделать такие шаблоны:

• *.*.computer.* — очередь, которая может обработать сообщения только от компьютеров без разницы где они находятся.
• eu-east.# — очередь, которая может обрабатывать сообщения только из зоны eu-east

Протоколы

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

Спустя какое-то время появились три открытых стандарта, которые сейчас повсеместно используются:

• Advanced Message Queuing Protocol (AMQP) — бинарный протокол, который проектировался для взаимодействия между различными вендорами и стал заменой существующих проприетарных протоколов. Основными особенностями AMQP является надежности и совместимость.
• Streaming Text Oriented Messaging Protocol (STOMP) — простой текстовый протокол обмена сообщениями, который очень похож на HTTP и работает поверх TCP.
• MQTT (formerly MQ Telemetry Transport) — очень простой и легковесный протокол, который разрабатывался для минимального использования трафика и работы в нестабильной сети. Все эти качества идеально подошли для использования протокола для общения между устройствами.

Материалы

• Message queues — отличная статья, которая описывает основные концепты работы очередей.
• The Big Little Guide to Message Queues — большой гайд в котором описано про причины создания очередей их свойства и особенности работы, а также кратный разбор самых популярных реализаций.