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

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

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

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

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

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

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

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

Метки времени действуют в качестве нейтрального и надежного центра, который точно фиксирует время прибытия сообщения в формате 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 , упрощают интеграцию всех этих элементов.

Следующие шаги

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

Дополнительный ресурс