В информатике, очереди сообщений и почтовые ящики являются программно-инженерные компоненты, как правило, используемые для связи между процессами (IPC), или для меж- нить связи в пределах того же самого процесса. Они используют очередь для обмена сообщениями - передачи управления или контента. Системы групповой коммуникации предоставляют аналогичные функции.
Парадигма очереди сообщений является аналогом шаблона издатель / подписчик и обычно является частью более крупной системы промежуточного программного обеспечения, ориентированной на сообщения. Большинство систем обмена сообщениями поддерживают в своих API модели как издатель / подписчик, так и модели очереди сообщений, например Java Message Service (JMS).
Очереди сообщений реализуют схему асинхронной связи между двумя или более процессами / потоками, при этом отправляющая и принимающая стороны не должны одновременно взаимодействовать с очередью сообщений. Сообщения, помещенные в очередь, хранятся до тех пор, пока получатель их не получит. Очереди сообщений имеют неявные или явные ограничения на размер данных, которые могут быть переданы в одном сообщении, и на количество сообщений, которые могут оставаться ожидающими в очереди.
Многие реализации очередей сообщений работают внутри операционной системы или приложения. Такие очереди существуют только для целей этой системы.
Другие реализации позволяют передавать сообщения между различными компьютерными системами, потенциально соединяя несколько приложений и несколько операционных систем. Эти системы очередей сообщений обычно обеспечивают функциональность устойчивости, чтобы гарантировать, что сообщения не будут «потеряны» в случае сбоя системы. Примеры коммерческих реализаций этого типа программного обеспечения для очередей сообщений (также известного как промежуточное ПО, ориентированное на сообщения ) включают IBM MQ (ранее MQ Series) и Oracle Advanced Queuing (AQ). Существует стандарт Java под названием Java Message Service, который имеет несколько проприетарных и бесплатных программных реализаций.
Операционные системы реального времени (ОСРВ), такие как VxWorks и QNX, поощряют использование очередей сообщений в качестве основного механизма межпроцессного или межпоточного взаимодействия. Это может привести к интеграции между передачей сообщений и планированием ЦП. Ранние примеры коммерческих ОСРВ, которые поощряли использование очереди сообщений для межпотоковой связи, также включают VRTX и pSOS +, обе из которых относятся к началу 1980-х годов. Язык программирования Erlang использует процессы для обеспечения параллелизма; эти процессы обмениваются данными асинхронно, используя очередь сообщений.
Программное обеспечение очереди сообщений может быть проприетарным, открытым исходным кодом или сочетанием того и другого. Затем он запускается либо локально на частных серверах, либо на внешних облачных серверах ( служба очереди сообщений ).
Примерами поставщиков промежуточного программного обеспечения для аппаратного обмена сообщениями являются Solace, Apigee и IBM MQ.
В типичной реализации очереди сообщений системный администратор устанавливает и настраивает программное обеспечение для организации очереди сообщений ( диспетчер очереди или брокер) и определяет именованную очередь сообщений. Или они регистрируются в службе очереди сообщений.
Затем приложение регистрирует программную процедуру, которая «прослушивает» сообщения, помещенные в очередь.
Второе и последующие приложения могут подключаться к очереди и передавать в нее сообщение.
Программное обеспечение администратора очередей хранит сообщения до тех пор, пока не подключится принимающее приложение, а затем вызывает зарегистрированную процедуру программного обеспечения. Затем принимающее приложение обрабатывает сообщение соответствующим образом.
Часто существует множество вариантов точной семантики передачи сообщений, в том числе:
Все эти соображения могут существенно повлиять на семантику транзакции, надежность и эффективность системы.
Исторически сложилось так, что организация очередей сообщений использовала закрытые проприетарные протоколы, ограничивающие возможность взаимодействия различных операционных систем или языков программирования в гетерогенном наборе сред.
Ранняя попытка сделать организации очередей сообщений более повсеместно была Sun Microsystems " JMS спецификацией, которая обеспечила Java -Только абстракции клиентского API. Это позволило разработчикам Java переключаться между поставщиками очередей сообщений аналогично тому, как это делают разработчики, использующие базы данных SQL. На практике, учитывая разнообразие методов и сценариев организации очередей сообщений, это не всегда было настолько практичным, насколько могло бы быть.
Появились три стандарта, которые используются в реализациях очередей сообщений с открытым исходным кодом:
Эти протоколы находятся на разных стадиях стандартизации и принятия. Первые два работают на том же уровне, что и HTTP, MQTT на уровне TCP / IP.
Некоторые патентованные реализации также использовать HTTP для обеспечения очереди сообщений с помощью некоторых реализаций, таких как Amazon «s SQS. Это связано с тем, что всегда можно наложить асинхронное поведение (что требуется для организации очереди сообщений) по синхронному протоколу с использованием семантики запроса-ответа. Однако в этом случае такие реализации ограничиваются базовым протоколом и могут быть не в состоянии предложить полную точность или набор опций, требуемых при передаче сообщений выше.
Многие из наиболее широко известных используемых протоколов связи работают синхронно. Протокол HTTP, используемый во всемирной паутине и в веб-службах, представляет собой очевидный пример, когда пользователь отправляет запрос на веб-страницу, а затем ожидает ответа.
Однако существуют сценарии, в которых синхронное поведение не подходит. Например, AJAX ( асинхронный JavaScript и XML ) можно использовать для асинхронной отправки текстовых, JSON или XML-сообщений для обновления части веб-страницы более актуальной информацией. Google использует этот подход для своего Google Suggest, функции поиска, которая отправляет частично набранные пользователем запросы на серверы Google и возвращает список возможных полных запросов, которые могут быть интересны пользователю в процессе набора текста. Этот список асинхронно обновляется по мере ввода пользователем.
Другие примеры асинхронности существуют в системах уведомления о событиях и системах публикации / подписки.
В обоих приведенных выше примерах для отправителя информации не имело бы смысла ждать, если, например, один из получателей потерпел крах.
Приложения не обязательно должны быть исключительно синхронными или асинхронными. Интерактивному приложению может потребоваться немедленно ответить на определенные части запроса (например, сообщить покупателю, что запрос на продажу был принят, и обработать обещание использовать запасы), но может поставить в очередь другие части (например, завершение расчета выставления счетов), пересылка данных в центральную бухгалтерскую систему и обращение ко всем другим службам), которые будут выполнены через некоторое время.
Во всех подобных ситуациях наличие подсистемы, которая выполняет очередь сообщений (или, альтернативно, системы широковещательного обмена сообщениями), может помочь улучшить поведение всей системы.
В UNIX есть две распространенные реализации очереди сообщений. Один является частью SYS V API, другой - частью POSIX.
UNIX SYS V реализует передачу сообщений, сохраняя массив связанных списков в виде очередей сообщений. Каждая очередь сообщений идентифицируется своим индексом в массиве и имеет уникальный дескриптор. У данного индекса может быть несколько возможных дескрипторов. UNIX предоставляет стандартные функции для доступа к функции передачи сообщений.
msgget()
IPC_CREAT
флаг установлен, он создает новую очередь сообщений с заданным ключом и возвращает его дескриптор.msgrcv()
msgctl()
IPC_RMID
флага. Очередь сообщений может быть удалена только ее создателем, владельцем или суперпользователем. API очереди сообщений POSIX.1-2001 является более поздним из двух API очереди сообщений UNIX. Он отличается от SYS V API, но предоставляет аналогичные функции. На странице mq_overview(7)
руководства unix представлен обзор очередей сообщений POSIX.
Графические пользовательские интерфейсы (GUI) используют очередь сообщений, также называемую очередью событий или очередью ввода, для передачи графических действий ввода, таких как щелчки мыши, события клавиатуры или другие вводимые пользователем данные, в прикладную программу. Оконная система помещает сообщения, указывающие на пользователя или другие события, такие как тики таймера или сообщения, отправленные другими потоками, в очередь сообщений. Приложение с графическим интерфейсом пользователя удаляет эти события по одному, вызывая подпрограмму, вызываемую getNextEvent()
или аналогичную в цикле событий, а затем вызывая соответствующую подпрограмму приложения для обработки этого события.