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

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

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

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

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

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

Переводить

Многие реализации очередей сообщений работают внутри Операционная система или в пределах заявление. Такие очереди существуют для того, чтобы система Только.[2][3][4]

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

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

Владение

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

Примеры на аппаратной основе промежуточное ПО для обмена сообщениями поставщики Утешение, Апиги, и IBM MQ.

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

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

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

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

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

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

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

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

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

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

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

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

  1. Расширенный протокол очереди сообщений (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 Suggest, функции поиска, которая отправляет частично набранные пользователем запросы на серверы Google и возвращает список возможных полных запросов, которые могут заинтересовать пользователя в процессе набора текста. Этот список асинхронно обновляется по мере ввода пользователем.

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

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

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

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

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

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

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

SYS V

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

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

POSIX

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

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

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

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

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

  1. ^ Модуль Dive Into Queue на Python. Обзор очередей сообщений POSIX
  2. ^ Системные очереди сообщений Win32. «О сообщениях и очередях сообщений». Пользовательский интерфейс Windows. Сеть разработчиков Microsoft. Архивировано из оригинал 17 марта 2012 г.. Получено 21 апреля, 2010.
  3. ^ Очереди сообщений Linux и POSIX. Обзор очередей сообщений POSIX В архиве 2012-05-04 в Wayback Machine на linux.die.net
  4. ^ Использование очередей сообщений Linux. Функции очереди сообщений Linux В архиве 2012-04-08 в Wayback Machine на www.civilized.com
  5. ^ Например, продукт MSMQ. «Очередь сообщений (MSMQ)». Сетевые коммуникации. Сеть разработчиков Microsoft. Получено 9 мая, 2009.
  6. ^ Бах, М.Дж. Дизайн операционной системы UNIX. ISBN  9780132017992.
  7. ^ Авраам Зильбершатц, Питер Б. Гэлвин. Концепции операционных систем. ISBN  9780201504804.
  8. ^ Картрайт, Корки. "Программирование GUI". Университет Райса: Роберт (Корки) Картрайт. Получено 27 июня, 2020.
  9. ^ Нистром, Роберт (2014). Шаблоны игрового программирования. ISBN  978-0990582908. Получено 27 июня, 2020.