Сеансы обмена сообщениями

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

Первый вход, первый выход (FIFO) шаблон

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

Отправитель может инициировать сеанс при отправке сообщений в раздел или очередь, задав свойству идентификатора сеанса уникальный идентификатор, определенный приложением. На уровне протокола AMQP 1.0 это значение сопоставляется со свойством group-id .

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

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

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

Для примеров используйте ссылки в разделе "Примеры ".

Функции сеанса

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

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

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

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

На предыдущем рисунке показаны три параллельных приемника сеансов. Один сеанс с SessionId = 4 не имеет активного, собственного клиента, что означает, что сообщения не передаются из этого конкретного сеанса. Сеанс во многом ведет себя как подочередь.

Блокировка сеанса, удерживаемая приемником сеанса, включает в себя блокировки сообщений, используемых режимом заверения peek-lock. Только один получатель может иметь блокировку сеанса. У получателя может быть много сообщений во время полета, но сообщения будут получены в порядке. Отказ от сообщения приводит к повторному выполнению того же сообщения следующей операцией получения.

Состояние сеанса сообщения

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

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

С точки зрения служебная шина состояние сеанса сообщения — это непрозрачный двоичный объект, который может содержать данные одного сообщения размером в 256 КБ для служебная шина standard и 100 МБ для служебная шина Premium. Состояние обработки относительно сеанса может храниться внутри состояния сеанса, или состояние сеанса может указывать на определенное расположение хранилища или запись базы данных, в которой хранятся такие сведения.

Объект приемника сеансов имеет методы для управления состоянием сеанса, SetState и GetState. Сеанс, который ранее не имел состояния сеанса, возвращает значение NULL для GetState. Ранее заданное состояние сеанса можно очистить, передав значение NULL методу SetState приемника.

Состояние сеанса сохраняется до тех пор, пока не очищено (возвращает NULL), даже если все сообщения в сеансе обработаны.

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

Влияние количества доставки

Определение количества доставки для каждого сообщения в контексте сеансов немного отличается от определения в отсутствие сеансов. Ниже приведена таблица, сводные данные о том, когда количество доставки увеличивается.

Максимальное количество доставок в сециях

Если сообщение в сеансе оставлено (например, из-за сбоя обработки), оно вновь доступно для получателя до тех пор, пока не будет превышено значение MaxDeliveryCount для очереди или подписки. Значение по умолчанию — 10. После превышения сообщение перемещается в очередь недоставленных писем (DLQ), а получатель продолжает получать последующие сообщения из сеанса.

Шаблон "запрос-ответ"

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

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

Последовательность против сеансов

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

Скажем, в очереди есть три сообщения и два потребителя.

1. Потребитель 1 получает сообщение 1.
2. Потребитель 2 получает сообщение 2.
3. Потребитель 2 завершает обработку сообщения 2 и принимает сообщение 3, в то время как Потребитель 1 еще не завершил обработку сообщения 1.
4. Потребитель 2 завершает обработку сообщения 3, но потребитель 1 ещё не завершил обработку сообщения 1.
5. Наконец, потребитель 1 завершает обработку сообщения 1.

Таким образом, сообщения обрабатываются в этом порядке: сообщение 2, сообщение 3 и сообщение 1. Если вам нужно обработать сообщение 1, 2 и 3, необходимо использовать сеансы.

Если сообщения нужно получить в порядке очереди, вам не нужно использовать сессии. Если сообщения должны обрабатываться в определённом порядке, используйте сессии. Задайте один и тот же идентификатор сеанса для сообщений, которые составляют одну группу, например, сообщения 1, 4 и 8 в одном наборе, а 2, 3 и 6 — в другом.

Срок действия сообщения

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

Образцы

Сеансы сообщений можно включить при создании очереди с помощью портала Azure, PowerShell, интерфейса командной строки (CLI), шаблона Resource Manager, .NET, Java, Python и JavaScript. Дополнительные сведения см. в разделе "Включение сеансов сообщений".

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

• .NET
  • Отправка и получение сеансовых сообщений
  • Использование обработчика сеанса
• Java
  • Отправить сообщения в сеанс
  • Получать сообщения из первой доступной сессии
  • Получить сообщения из определенной сессии
  • Процессируйте все сообщения сеанса с помощью процессора
• Python
  • Отправка и получение сообщений из очереди с поддержкой сеанса
  • Получение сообщений из нескольких сеансов параллельно с использованием пула потоков
• JavaScript
  • Отправка сообщений в очереди или подписки с поддержкой сеанса и получение из них
  • Постоянно просматривает все доступные сеансы
  • Использовать состояние сеанса

Связанный контент

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