Обнаружение дубликата в Служебная шина Azure

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

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

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

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

Замечание

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

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

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

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

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

Это важно

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

Замечание

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

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

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

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

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

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

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

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

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

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

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

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

  • Last updated on