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

«Почтовый ящик (компьютерный)» перенаправляется сюда. Формат файла см. в Mbox .

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

Парадигма очереди сообщений является аналогом шаблона издатель/подписчик и обычно является частью более крупной системы промежуточного программного обеспечения, ориентированной на сообщения . модели издателя/подписчика и очереди сообщений Большинство систем обмена сообщениями поддерживают в своих API , например Java Message Service (JMS).

Шаблон «Конкурирующие потребители» позволяет нескольким одновременным потребителям обрабатывать сообщения в одной очереди сообщений.

Перевод и право собственности

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

Переводить

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

Другие реализации позволяют передавать сообщения между различными компьютерными системами, потенциально соединяя несколько приложений и несколько операционных систем. Эти системы очередей сообщений обычно обеспечивают функциональность устойчивости , гарантирующую, что сообщения не «потеряются» в случае сбоя системы. Примеры коммерческих реализаций такого рода программного обеспечения для организации очередей сообщений (также известного как промежуточное программное обеспечение, ориентированное на сообщения ) включают IBM MQ (ранее MQ Series) и Oracle Advanced Queuing (AQ). Существует стандарт Java под названием Java Message Service , который имеет несколько проприетарного и бесплатного программного обеспечения реализаций .

Операционные системы реального времени (RTOS), такие как VxWorks и QNX, поощряют использование очередей сообщений в качестве основного механизма взаимодействия между процессами или потоками. Это может привести к интеграции между передачей сообщений и планированием ЦП. Ранние примеры коммерческих ОСРВ, которые поощряли использование очередей сообщений для межпоточной связи, также включают VRTX и pSOS +, оба из которых датируются началом 1980-х годов. Язык программирования Erlang использует процессы для обеспечения параллелизма; эти процессы взаимодействуют асинхронно, используя очередь сообщений.

Право собственности

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

• Собственные варианты имеют самую долгую историю и включают в себя продукты с момента появления очередей сообщений, такие как IBM MQ , и продукты, привязанные к конкретным операционным системам, такие как Microsoft Message Queuing (MSMQ) . Поставщики облачных услуг также предоставляют свои собственные решения, такие как Amazon Simple Queue Service (SQS), StormMQ, Solace и IBM MQ .
• программного обеспечения для обмена сообщениями с открытым исходным кодом Выбор промежуточного включает Apache ActiveMQ , Apache Kafka , Apache Qpid , Apache RocketMQ , Enduro/X , JBoss Messaging , JORAM , RabbitMQ , Sun Open Message Queue и Tarantool .

Примерами поставщиков аппаратного промежуточного программного обеспечения для обмена сообщениями являются Solace , Apigee и IBM MQ .

Использование

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

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

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

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

Часто существует множество вариантов точной семантики передачи сообщений, в том числе:

• Долговечность – сообщения могут храниться в памяти, записываться на диск или даже передаваться в СУБД , если необходимость обеспечения надежности указывает на более ресурсоемкое решение.
• Политики безопасности – какие приложения должны иметь доступ к этим сообщениям?
• Политики очистки сообщений – очереди или сообщения могут иметь « время жизни ».
• Фильтрация сообщений. Некоторые системы поддерживают фильтрацию данных, поэтому подписчик может видеть только сообщения, соответствующие некоторым заранее заданным интересующим критериям.
• Политики доставки: нужно ли нам гарантировать, что сообщение будет доставлено хотя бы один раз или не более одного раза?
• Политики маршрутизации – в системе с множеством серверов очередей какие серверы должны получать сообщение или сообщения очереди?
• Политика пакетной обработки: должны ли сообщения доставляться немедленно? Или системе стоит немного подождать и попытаться доставить много сообщений одновременно?
• Критерии организации очереди: когда сообщение следует считать «поставленным в очередь»? Когда это есть в одной очереди? Или когда оно было перенаправлено хотя бы в одну удаленную очередь? Или во все очереди?
• Уведомление о получении. Издателю может потребоваться знать, когда некоторые или все подписчики получили сообщение.

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

Стандарты и протоколы

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

Первой попыткой сделать очередь сообщений более повсеместной была Sun Microsystems компании спецификация JMS , которая обеспечивала только для Java абстракцию клиентского API . Это позволило разработчикам Java переключаться между поставщиками очередей сообщений аналогично тому, как это делают разработчики, использующие базы данных SQL . На практике, учитывая разнообразие методов и сценариев организации очередей сообщений, это не всегда было настолько практично, насколько могло бы быть.

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

1. Advanced Message Queuing Protocol (AMQP) – многофункциональный протокол очереди сообщений, одобренный как ISO/IEC 19464 с апреля 2014 г.
2. Протокол потокового тексто-ориентированного обмена сообщениями (STOMP) - простой протокол тексто-ориентированных сообщений.
3. MQTT (ранее MQ Telemetry Transport) — облегченный протокол очереди сообщений, специально для встроенных устройств.

Эти протоколы находятся на разных стадиях стандартизации и принятия. Первые два работают на том же уровне, что и HTTP , MQTT — на уровне TCP/IP .

Некоторые проприетарные реализации также используют HTTP для обеспечения очереди сообщений в некоторых реализациях, например Amazon от SQS . Это связано с тем, что всегда возможно наложить асинхронное поведение (что требуется для организации очереди сообщений) на синхронный протокол, используя семантику запрос-ответ. Однако в этом случае такие реализации ограничены базовым протоколом и могут быть не в состоянии обеспечить полную точность или набор опций, требуемых при передаче сообщений выше.

Синхронный и асинхронный

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

Однако существуют сценарии, в которых синхронное поведение неприемлемо. Например, AJAX ( асинхронный JavaScript и XML ) можно использовать для асинхронной отправки текстовых сообщений, сообщений JSON или XML для обновления части веб-страницы более актуальной информацией. Google использует этот подход для своего Google Offer, функции поиска, которая отправляет частично набранные пользователем запросы на серверы Google и возвращает список возможных полных запросов, которые могут быть интересны пользователю в процессе набора. Этот список асинхронно обновляется по мере ввода данных пользователем.

Другие асинхронные примеры существуют в системах уведомления о событиях и публикации/подписки системах .

• Приложению может потребоваться уведомить другое приложение о том, что произошло событие, но ему не нужно ждать ответа.
• В системах публикации/подписки приложение «публикует» информацию для чтения любым количеством клиентов.

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

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

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

Реализация в UNIX

существуют две распространенные реализации очереди сообщений В UNIX . Один из них является частью SYS V API, другой — частью POSIX .

SYS V

UNIX SYS V реализует передачу сообщений, сохраняя массив связанных списков в виде очередей сообщений. Каждая очередь сообщений идентифицируется своим индексом в массиве и имеет уникальный дескриптор. Данный индекс может иметь несколько возможных дескрипторов. UNIX предоставляет стандартные функции для доступа к функции передачи сообщений.

msgget()

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

msgrcv()

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

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

msgctl()

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

ПОСИКС

API очереди сообщений POSIX.1-2001 является более поздним из двух API очереди сообщений UNIX. Он отличается от API SYS V, но предоставляет аналогичные функции. Страница руководства unix mq_overview(7) предоставляет обзор очередей сообщений POSIX.

Графические пользовательские интерфейсы

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

См. также

• Расширенный протокол очереди сообщений (AMQP)
• Простая служба очередей Amazon
• Апач ActiveMQ
• Апач Qpid
• Сельдерей (программное обеспечение)
• Германия
• Интеграционная шина IBM
• IBM MQ
• Служба сообщений Java
• MQTT
• Промежуточное программное обеспечение, ориентированное на сообщения , (категория)
• Служба очереди сообщений Microsoft (известная в просторечии как MSMQ)
• НАТС
• Облачная служба обмена сообщениями Oracle
• КроликMQ
• Редис
• TIBCO Служба корпоративных сообщений
• Enduro/X Платформа промежуточного программного обеспечения
• НольMQ