Срок действия сообщений (время жизни) в служебной шине Azure

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

Время жизни и истечения срока действия в формате UTC

Вы можете контролировать срок действия любого отдельного сообщения, задав системное свойство время жизни, указывающее относительную длительность. Срок действия становится абсолютным моментом при вводе сообщения в сущность. В этот момент свойство expires-at-utc принимает значение enqueued-time-utc + time-to-live. Параметр времени жизни (TTL) для сообщения с брокером не соблюдается, когда клиенты не прослушивают активно.

Примечание.

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

После того, как момент expires-at-utc пройдет, сообщения станут недоступными для получения. Срок действия не касается сообщений, доставка которых в текущий момент заблокирована. Такие сообщения обрабатываются обычным образом. Если срок действия блокировки истекает или сообщение отбрасывается, его срок действия вступает в силу немедленно. Во время того, как сообщение заблокировано, приложение может иметь сообщение, срок действия которого истек. Будет ли приложение обрабатывать это сообщение или отбросит его, определяется разработчиком.

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

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

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

Например, если ScheduledEnqueueTimeUtc задано на 5 минут от UtcNow, а TimeToLive на 10 минут, сообщение истекает через 5 + 10 = 15 минут. Сообщение появляется в очереди через пять минут, и затем начинается отсчет 10 минут.

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

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

Свойство expires-at-utc так задумано. Если значение TTL сообщения не задано и задано только значение TTL сущности, expires-at-utc — это вычисляемое значение, которое определяется в пути Receive/Peeklock, но не в пути Peek. Если сообщение имеет TTL, система вычисляет истекает-в-формате-UTC при отправке и сохраняет. В этом случае Peek возвращает правильные значения параметра истечение в формате UTC.

Примечание.

• Значение времени жизни по умолчанию для брокерского сообщения — максимально возможное значение для со знаком 64-разрядного целого числа, если не указано иное.
• Для сущностей обмена сообщениями (очереди и разделы) срок действия по умолчанию также является самым большим возможным значением для подписанного 64-разрядного целого числа для стандартных и премиум-уровней служебной шины . Для базового уровня срок действия по умолчанию (также максимальный) составляет 14 дней.
• Если для темы определяется меньший TTL, чем у подписки, применяется TTL темы.

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

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

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

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

Временные сущности

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

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

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

Внимание

Установка уровня блокировки Azure Resource Manager на CanNotDelete в пространстве имен или на более высоком уровне не предотвращает удаление сущностей с AutoDeleteOnIdle. Если вы хотите запретить удаление сущности, присвойте свойству AutoDeleteOnIdle значение DataTime.MaxValue.

Неактивность

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

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

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

Пакеты SDK

Установите свойство времени жизни с помощью наборов для разработки ПО (SDK).

• Установка срока жизни для сообщения: .NET, Java, Python, JavaScript
• Установка срока жизни по умолчанию для очереди: .NET, Java, Python, JavaScript
• Чтобы задать срок жизни по умолчанию для топика: .NET, Java, Python, JavaScript
• Чтобы задать время существования по умолчанию для подписки: .NET, Java, Python, JavaScript

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

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

Чтобы узнать о расширенных функциях Служебная шина Azure, см. раздел Обзор расширенных функций.