Обнаружение повторяющихся записей

  • Статья

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

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

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

Примечание.

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

Как это работает

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