Поделиться через

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

  • Статья

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

Примечание.

Ценовая категория "Базовый" Служебной шины не поддерживает сеансы, Уровни Стандартный и Премиум поддерживают сеансы. Различия между этими ценовыми категориями приведены на странице цен на Служебную шину.

Метод простой очереди (FIFO)

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

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

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

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

Внимание

Если сеансы включены для очереди или подписки, клиентские приложения больше не смогут отправлять и получать обычные сообщения. Все сообщения должны быть отправлены в составе сеанса (путем установки идентификатора сеанса) и получены путем приема сеанса. Клиенты по-прежнему могут просмотреть очередь или подписку с включенными сеансами. Просмотр сообщений.

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

Например, используйте ссылки в разделе Дальнейшие действия.

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

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

Diagram that shows how the Sessions feature preserves an ordered delivery.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сценарий Число доставок сообщений увеличивается
Сеанс был принят, но блокировка сеанса истекла (из-за превышения времени ожидания). Да
Сеанс принимается, сообщения в сеансе не завершены (даже если они заблокированы), и сеанс закрыт. No
Сеанс был принят, сообщения были обработаны, а затем сеанс был явным образом закрыт. N/A (это стандартный поток. Здесь сообщения удаляются из сеанса)

Метод "запроса и ответа"

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

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

Примечание.

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

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

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

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

  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, интерфейса командной строки, шаблона Resource Manager, .NET, Java, Python и JavaScript. Дополнительные сведения см. в разделе Включение сеансов сообщений.

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