Поиск повторяющихся данных

  • Статья

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

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

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

Примечание.

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

Принцип работы

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

Элемент управления приложением идентификатора является важным, так как только это позволяет приложению связывать MessageId контекст бизнес-процесса, из которого он может быть прогнозируемо восстановлен при возникновении сбоя.

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

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

Внимание

  • Если секционирование включено, для определения уникальности используется MessageId+PartitionKey. Если сеансы включены, ключ секции и идентификатор сеанса должны быть одинаковыми.
  • Если секционирование отключено (по умолчанию), для определения уникальности используется только MessageId.
  • Дополнительные сведения о ключах PartitionKeyMessageIdсекций см. в SessionIdразделе "Использование ключей секций".
  • При использовании секционирования и отправки пакетов сообщений следует убедиться, что они не содержат свойств, определяющих секции. Так как дедупликация использует явно заданные идентификаторы сообщений для определения уникальности, не рекомендуется использовать дедупликацию и пакетную обработку вместе с секционированием.

Примечание.

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

Интервал обнаружения повторений

Помимо простого включения обнаружения повторяющихся данных, можно также настроить размер периода времени журнала повторяющихся обнаружений, в течение которого хранятся идентификаторы сообщений. По умолчанию это значение для очередей и разделов равно 10 минут. Минимальное значение составляет 20 секунд, а максимальное — 7 дней.

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

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

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

Включить обнаружение повторений можно с помощью портала Azure, PowerShell, интерфейса командной строки, шаблона Диспетчера ресурсов, .NET, Java, Python и JavaScript. Дополнительные сведения см. в разделе Настройка обнаружения повторяющихся сообщений.

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

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

Примеры для старых клиентских библиотек .NET и Java см. здесь:

30 сентября 2026 г. мы удалим библиотеки пакета SDK Служебная шина Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus и com.microsoft.azure.servicebus, которые не соответствуют рекомендациям по пакету SDK Azure. Мы также завершим поддержку протокола SBMP, поэтому вы больше не сможете использовать этот протокол после 30 сентября 2026 года. Перейдите в последние библиотеки пакета SDK Azure, которые предлагают критически важные обновления системы безопасности и улучшенные возможности до этой даты.

Хотя старые библиотеки по-прежнему могут использоваться после 30 сентября 2026 года, они больше не будут получать официальную поддержку и обновления от Майкрософт. Дополнительные сведения см. в объявлении о выходе на пенсию в службу поддержки.