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

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

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

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

СОДЕРЖАНИЕ

  • 1 Передача и право собственности
    • 1.1 Пересылка
    • 1.2 Право собственности
  • 2 Использование
  • 3 Стандарты и протоколы
  • 4 Синхронный и асинхронный
  • 5 Реализация в UNIX
    • 5.1 SYS V
    • 5.2 POSIX
  • 6 Графические пользовательские интерфейсы
  • 7 См. Также
  • 8 ссылки

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

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

Переводить

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

Другие реализации позволяют передавать сообщения между различными компьютерными системами, потенциально соединяя несколько приложений и несколько операционных систем. Эти системы очередей сообщений обычно обеспечивают функциональность устойчивости, чтобы гарантировать, что сообщения не будут «потеряны» в случае сбоя системы. Примеры коммерческих реализаций этого типа программного обеспечения для очередей сообщений (также известного как промежуточное ПО, ориентированное на сообщения ) включают 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. На практике, учитывая разнообразие методов и сценариев организации очередей сообщений, это не всегда было настолько практичным, насколько могло бы быть.

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

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

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

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

Синхронный против асинхронного

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

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

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

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

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

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

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

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

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

SYS V

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

msgget()
Этот системный вызов принимает ключ в качестве аргумента и возвращает дескриптор очереди с совпадающим ключом, если он существует. Если он не существует и IPC_CREAT флаг установлен, он создает новую очередь сообщений с заданным ключом и возвращает его дескриптор.
msgrcv()
Используется для получения сообщения из заданного дескриптора очереди. Вызывающий процесс должен иметь разрешения на чтение для очереди. Он бывает двух типов.
  • Блокирование приема переводит ребенка в режим сна, если он не может найти запрошенный тип сообщения. Он спит до тех пор, пока в очередь не появится другое сообщение, а затем просыпается, чтобы снова проверить.
  • Неблокирующий прием немедленно возвращается вызывающему, указывая на то, что он не удался.
msgctl()
Используется для изменения параметров очереди сообщений, таких как владелец. Что наиболее важно, он используется для удаления очереди сообщений путем передачи IPC_RMID флага. Очередь сообщений может быть удалена только ее создателем, владельцем или суперпользователем.

POSIX

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

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

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

Смотрите также

Рекомендации

Последняя правка сделана 2024-01-02 08:16:50
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте