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

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

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

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

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

Замечание

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

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

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

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

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

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

Это важно

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

Замечание

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

Размер окна обнаружения дубликата

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

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

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

Дальнейшие шаги

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

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

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

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

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

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