Очереди, разделы и подписки служебной шины

  • Статья

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

Внимание

Если вы не знакомы с Служебная шина Azure, ознакомьтесь с тем, что такое Служебная шина Azure? прежде чем пройти эту статью.

Очереди

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

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

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

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

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

Создание очередей

Очереди можно создать с помощью одного из следующих параметров:

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

Режимы приема

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

  • Получить и удалить сообщение. В этом режиме, когда служебная шина получает запрос от потребителя, она помечает сообщение как потребленное и возвращает его в приложение потребителя. Режим "Получить и удалить сообщение" представляет собой самую простую модель, которая лучше всего работает в ситуациях, когда для приложения допустимо не обрабатывать сообщение при сбое. Чтобы понять этот сценарий, рассмотрим сценарий, в котором объект-получатель выдает запрос на получение и выходит из строя до его обработки. Как служебная шина помечает сообщение как используемое, приложение начинает потреблять сообщения после перезапуска. Оно пропустит сообщение, которое потребило до сбоя. Этот процесс часто вызывается по крайней мере один раз в обработке.
  • Просмотр и блокировка В этом режиме прием сообщения становится двухэтапной операцией, что позволяет поддерживать приложения, для которых недопустимо пропускать сообщения.

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

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

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

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

      Примечание.

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

Разделы и подписки

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

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

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

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

Создание разделов и подписок

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

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

Правила и действия

Во многих ситуациях сообщения с определенными характеристиками должны обрабатываться разными способами. Для этого можно настроить подписки, обеспечивающие поиск сообщений с нужными свойствами, после чего можно определенным образом изменить эти свойства. Хотя служебная шина подписки видят все сообщения, отправленные в раздел, можно скопировать только подмножество этих сообщений в очередь виртуальной подписки. Это возможно благодаря использованию фильтров подписок. Такие изменения называются действиями фильтров. При создании подписки можно задать выражение фильтра, которое работает со свойствами сообщения. Это могут быть как системные свойства (например, Метка), так и настраиваемые свойства приложения (например, StoreName). В этом случае выражение фильтра SQL задавать необязательно. Без выражения фильтра SQL все действия фильтра, определенные в подписке, выполняются во всех сообщениях для этой подписки.

Полный рабочий пример см. в примере TopicFilters на сайте GitHub. Дополнительные сведения о фильтрах см. в статье Фильтры и действия разделов.

Сущности в службе сообщений Java (JMS) версии 2.0

Через API службы сообщений Java (JMS) версии 2.0 доступны следующие сущности:

  • Временные очереди
  • Временные разделы
  • общие устойчивые подписки;
  • Устойчивые подписки без общего доступа
  • общие неустойчивые подписки;
  • Необщие неустойчивые подписки

Дополнительные сведения: сущности JMS 2.0 и как их использовать.

Экспресс-сущности

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

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

Кроме того, с течением времени многие оптимизации были выполнены в служебная шина, что означает, что преимущества пропускной способности и задержки экспресс-сущностей в настоящее время минимальны. Кроме того, уровень "Премиум" служебная шина не поддерживает сущности Express. Из-за этого в настоящее время не рекомендуется использовать эту функцию.

Следующие шаги

Попробуйте примеры на выбранном языке:

Для примеров, использующих старые клиентские библиотеки .NET и Java, используйте следующие ссылки:

30 сентября 2026 г. мы удалим библиотеки пакета SDK Служебная шина Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus и com.microsoft.azure.servicebus, которые не соответствуют рекомендациям по пакету SDK Azure. Мы также завершим поддержку протокола SBMP, поэтому вы больше не сможете использовать этот протокол после 30 сентября 2026 года. Перейдите в последние библиотеки пакета SDK Azure, которые предлагают критически важные обновления системы безопасности и улучшенные возможности до этой даты.

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