Как Azure Service Bus идентифицирует дублирующее сообщение?

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

Что мне интересно, так это то, как служба определяет два сообщения на самом деле дублирует:

  • Какие свойства сообщения рассматриваются?
  • Рассматривается ли содержание сообщения?
  • Если я отправляю два сообщения с одним и тем же контентом, но разные свойства сообщений, считаются ли они дублирующими?

ОТВЕТЫ

Ответ 1

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

Литература:

Документация MSDN: http://msdn.microsoft.com/en-us/library/windowsazure/hh367516.aspx

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

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

Я также быстро протестировал это и отправил в 5 сообщений в очередь с RequiresDuplicateDetection установленным значением true, все с тем же содержимым, но с другим MessageIds. Затем я получил все пять сообщений. Затем я сделал обратное, где у меня было сопоставление MessageIds, но разные полезные нагрузки, и было восстановлено только одно сообщение.

Ответ 2

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

            var message = new BrokeredMessage(json)
            {
                MessageId = GetMessageId(input, extra)
            };

            // Delay 30 seconds for Message to process
            // So that Duplication Detection Engine has enought time to reject duplicated message
            message.ScheduledEnqueueTimeUtc = DateTime.UtcNow.AddSeconds(30);