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

Последовательность сообщений и метки времени

  • Статья

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

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

Порядковый номер

Это SequenceNumber уникальное 64-разрядное целое число, назначенное сообщению, так как оно принимается и сохраняется брокером и функциями в качестве внутреннего идентификатора. Для секционированных сущностей верхние 16 бит отражают идентификатор раздела. Порядковые числа переключения на ноль, если диапазон секционирования исчерпан 64-разрядной или 48-разрядной (за исключением 16 битов для идентификатора секции).

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

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

Метка времени

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

Примечание.

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

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

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

Дополнительные сведения см. в служебная шина сеансах сообщений.

Запланированные сообщения

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

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

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

  • Используйте стандартный API отправки, но перед отправкой задайте свойство Scheduled​Enqueue​Time​Utc для сообщения.
  • Используйте API-интерфейс для планировки сообщений, затем передайте как нормальное сообщение, так и запланированное время. API возвращает запланированное сообщение SequenceNumber, которое позже можно использовать для отмены запланированного сообщения при необходимости.

Запланированные сообщения и их номера последовательности можно также обнаружить при просмотре сообщений.

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

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

Примечание.

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

Использование запланированных сообщений с рабочими процессами

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

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

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

Дополнительные сведения об обмене сообщениями через служебную шину см. в следующих статьях: