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

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

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

Чтобы обеспечить обработку "FIFO" при обработке сообщений из очередей или подписок Service Bus, используйте сеансы. Служебная шина не предписывает характер связи между сообщениями и не задаёт конкретную модель для определения начала или конца последовательности сообщений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

• .СЕТЬ
  • Отправка и получение сообщений сеанса
  • Использование обработчика сеансов
• Ява
  • Отправка сообщений в сеанс
  • Получать сообщения из первого доступного сеанса
  • Получение сообщений из определенного сеанса
  • Обработка всех сообщений сеанса с помощью процессора
• Питон
  • Отправка и получение сообщений из очереди с поддержкой сеанса
  • Получение сообщений из нескольких доступных сеансов параллельно с использованием пула потоков
• JavaScript
  • Отправка и получение сообщений из очередей или подписок с поддержкой сеанса
  • Постоянно считывайте все доступные сеансы
  • Использование состояния сеанса

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

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