Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Служебная шина Azure поддерживает надежную очередь сообщений и устойчивую публикацию и подписку на сообщения. Сущности обмена сообщениями, которые образуют основную часть возможностей обмена сообщениями в шине обслуживания, включают очереди, разделы и подписки.
В этой статье объясняется, какие основные сущности системы обмена сообщениями, их преимущества и когда следует применять каждую из них в архитектуре приложения.
Внимание
Если вы не знакомы с служебной шиной Azure, ознакомьтесь с введением в служебную шину Azure , прежде чем перейти к этой статье.
Выбор между очередями и разделами
В следующей таблице приведены основные различия между очередями и топиками, которые помогут вам выбрать правильный объект обмена сообщениями для вашего сценария.
| Функция | Очереди | Разделы и подписки |
|---|---|---|
| Шаблон связи | Точка — точка | Публикация/подписка (один ко многим) |
| Доставка сообщений | Один потребитель на каждое сообщение | Несколько подписчиков могут получать копии |
| Сценарий использования | Распределение задач, выравнивание нагрузки | Трансляция событий, сценарии фан-аута |
| Фильтрация | Не поддерживается | Фильтры подписок для выборочной доставки сообщений |
Очереди
Очереди предлагают доставку сообщений одному или нескольким конкурирующим потребителям в порядке FIFO (первым пришел, первым вышел). Иными словами, обычно получатели принимают и обрабатывают сообщения в том порядке, в котором они были добавлены в очередь, и каждое сообщение принимается и обрабатывается только одним потребителем.
Преимущества использования очередей
| Преимущества | Description |
|---|---|
| Темпоральное разъединение | Производители (отправители) и потребители (получатели) не должны одновременно отправлять и получать сообщения, так как сообщения хранятся в очереди. Производитель не должен ждать ответа от потребителя, чтобы продолжить обработку. |
| Выравнивание нагрузки | Производители и потребители могут отправлять и получать сообщения по разным тарифам. Потребляемое приложение должно обрабатывать только среднюю нагрузку, а не пиковую нагрузку, экономя затраты на инфраструктуру. |
| Конкурирующие потребители | Несколько рабочих процессов могут считывать из очереди, при этом каждое сообщение обрабатывается только одним работником. Эта балансировка нагрузки на основе вытягивания позволяет сотрудникам обрабатывать по своей максимальной скорости. |
| Слабое сцепление | Поскольку производители и потребители не знают друг друга, потребитель может быть обновлен, не влияя на производителя. |
Создание очередей
Очереди можно создать с помощью одного из следующих параметров:
служебная шина поддерживает иерархические имена сущностей, в которых в качестве разделителей используются символы прямой косой черты, например orders/region/west. При использовании инструментов на основе ARM (портал, CLI, PowerShell или шаблонов) замените / именами ~ сущностей. Подробнее см. Имена сущностей с косыми чертами.
Затем отправьте и получите сообщения с помощью клиентов, написанных на языках программирования, включая следующие:
Режимы приема
Можно указать два разных режима, в которых потребители могут получать сообщения из служебная шина.
Режим получения и удаления
Когда служебная шина получает запрос от потребителя, он помечает сообщение как потребляемое и возвращает его в приложение-получатель. Этот режим является самой простой моделью и лучше всего подходит для сценариев, когда приложение может не обрабатывать сообщение, если происходит сбой.
Если потребитель завершает работу перед обработкой сообщения, сообщение теряется, так как служебная шина уже помечена как потребляемая. Этот процесс часто называется не более одного раза обработкой.
Режим блокировки для просмотра
Операция получения становится двухэтапной, что позволяет поддерживать приложения, которые не могут терпеть отсутствующие сообщения:
- Находит следующее сообщение, которое будет использоваться, блокирует его, чтобы другие потребители не получали его, а затем возвращает сообщение приложению.
- Завершив обработку сообщения, приложение передает на служебную шину запрос на выполнение второго этапа процесса приема. Затем служба помечает сообщение как используемое.
Обработка сбоев в режиме блокировки для просмотра:
- Отказ. Если приложение не может обработать сообщение, он может запросить служебную шину, чтобы отказаться от сообщения. Служебная шина разблокирует сообщение и делает его доступным для получения снова.
- Время ожидания блокировки: если приложению не удается обработать сообщение до истечения срока ожидания блокировки, служебная шина разблокирует сообщение и делает его доступным для получения снова.
- Сбой приложения: Если приложение завершает работу после обработки сообщения, но до его завершения, служебная шина повторно отправляет сообщение при перезапуске приложения. Такой подход часто называют по крайней мере однократной обработкой —
Если сценарий не может терпеть повторную обработку, добавьте в приложение дополнительную логику для обнаружения дубликатов. Дополнительные сведения см. в разделе "Обнаружение повторов", которое называется точно один раз обработкой.
Примечание.
Дополнительные сведения об этих двух режимах работы обратитесь к разделу «Настройка операций приема».
Разделы и подписки
Очередь позволяет обработать сообщение одному потребителю. В отличие от очередей, темы и подписки обеспечивают возможность связи "один ко многим" в рамках схемы публикации и подписки. Это полезно, когда требуется масштабирование на большое число получателей. Каждое опубликованное сообщение становится доступным по каждой зарегистрированной подписке на соответствующий раздел. Издатель отправляет сообщение в раздел, а один или несколько подписчиков получают копию сообщения.
Издатели отправляют сообщения в раздел так же, как и в очередь. Однако потребители не получают сообщения напрямую от темы. Вместо этого потребители получают сообщения из подписок на тему. Подписка на тему напоминает виртуальную очередь, которая получает копии сообщений, отправленных в эту тему. Потребители получают сообщения из подписки так же, как и из очереди. Функциональность отправки сообщений из очереди напрямую соответствует теме, а функциональность приема сообщений из нее — подписке. Помимо прочего, эта возможность означает, что подписки также поддерживают схемы для очередей, описанные ранее в этом разделе, в том числе конкуренцию потребителей, временное разделение, а также выравнивание и балансировку нагрузки.
Фильтры подписок
Подписки могут определять, какие сообщения они предпочитают получать от темы. Эти сообщения определяются в одном или нескольких именованных правилах подписки. Каждое правило состоит из условия фильтра, которое выбирает определенные сообщения и при необходимости содержит действие , которое заметит выбранное сообщение. По умолчанию подписка на раздел получает все сообщения, отправленные в раздел. Подписка имеет начальное правило по умолчанию с истинным фильтром, который позволяет выбирать все сообщения в подписку. Правило по умолчанию не имеет связанного действия. Вы можете определить фильтры с правилами и действиями для подписки, чтобы подписка получала только подмножество сообщений, отправленных в тему.
Дополнительные сведения о фильтрах см. в разделе "Фильтры" и "Действия".
Создание разделов и подписок
Создание раздела подобно созданию очереди, как показано в примере, приведенном в предыдущем разделе. Вы можете создавать разделы и подписки с помощью одного из следующих вариантов:
Затем отправьте сообщения в тему и получите сообщения от подписок с помощью клиентов, написанных на языках программирования, включая следующие:
Правила и действия
Во многих ситуациях сообщения с определенными характеристиками должны обрабатываться разными способами. Чтобы включить эту обработку, можно настроить подписки для поиска сообщений с нужными свойствами, а затем выполнить определенные изменения этих свойств. Хотя служебная шина подписки видит все сообщения, отправленные в тему, можно скопировать только подмножество этих сообщений в виртуальную очередь подписки. Это возможно благодаря использованию фильтров подписок. Такие изменения называются действиями фильтров. При создании подписки можно задать выражение фильтра, которое работает со свойствами сообщения. Это могут быть как системные свойства (например, Метка), так и настраиваемые свойства приложения (например, StoreName). В этом случае выражение фильтра SQL задавать необязательно. Без выражения фильтра SQL все действия фильтра, определенные в подписке, выполняются во всех сообщениях для этой подписки.
Полный рабочий пример см. в примере TopicFilters на сайте GitHub. Дополнительные сведения о фильтрах см. в статье Фильтры и действия разделов.
Служба сообщений Java (JMS) 2.0 - сущности
Через API службы сообщений Java (JMS) версии 2.0 доступны следующие сущности:
- Временные очереди
- Временные темы
- общие устойчивые подписки;
- Неразделяемые устойчивые подписки
- Общие временные подписки
- Непостоянные неразделяемые подписки
Дополнительные сведения: сущности JMS 2.0 и как их использовать.
Экспресс-сущности
Внимание
Для новых приложений не рекомендуется использовать экспресс-сущности. Преимущества пропускной способности и задержки в настоящее время минимальны из-за оптимизации в служебная шина. Уровень Premium в служебная шина не поддерживает сущности Express.
Экспресс-сущности были созданы для сценариев высокой пропускной способности и уменьшения задержки. При использовании экспресс-сущностей, если сообщение отправляется в очередь или раздел, оно не сразу хранится в хранилище сообщений. Вместо этого сообщение изначально кэшируется в памяти. Сообщения, оставшиеся в сущности, записываются в хранилище сообщений с задержкой. В этот момент они защищены от потери данных из-за сбоя.
В обычных сущностях любая операция среды выполнения (например, Send, Complete, Abandon, Deadletter) сначала сохраняется в хранилище и только после этого она признается успешной для клиента. В экспресс-сущностях операция времени выполнения сначала подтверждается как успешная для клиента, а только потом в ленивом режиме сохраняется в хранилище. В результате, когда компьютер перезагружается или когда возникает проблема с оборудованием, некоторые признанные операции среды выполнения могут не сохраняться вообще. В этом случае клиент получает меньшую задержку и более высокую пропускную способность с экспресс-сущностями за счет потенциальной потери данных и/или повторной доставки сообщений.
Следующие шаги
Попробуйте примеры на выбранном языке:
- Примеры для клиентской библиотеки Служебной шины Azure для .NET (последняя версия)
- Примеры для клиентской библиотеки Служебной шины Azure для Java (последняя версия)
- Примеры для клиентской библиотеки Служебной шины Azure для Python
- Примеры для клиентской библиотеки Служебной шины Azure для JavaScript
- Примеры для клиентской библиотеки Служебной шины Azure для TypeScript
Для примеров, использующих старые клиентские библиотеки .NET и Java, используйте следующие ссылки:
- Примеры для клиентской библиотеки Служебной шины Azure для .NET (прежние версии)
- Примеры для клиентской библиотеки Служебной шины Azure для Java (прежние версии)
30 сентября 2026 г. мы удалим библиотеки пакета SDK Служебная шина Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus и com.microsoft.azure.servicebus, которые не соответствуют рекомендациям по пакету SDK Azure. Мы также завершим поддержку протокола SBMP, поэтому вы больше не сможете использовать этот протокол после 30 сентября 2026 года. Перейдите в последние библиотеки пакета SDK Azure, которые предлагают критически важные обновления системы безопасности и улучшенные возможности до этой даты.
Хотя старые библиотеки по-прежнему могут использоваться после 30 сентября 2026 года, они больше не будут получать официальную поддержку и обновления от Майкрософт. Дополнительные сведения см. в объявлении о прекращении поддержки.