Compartilhar via

Detecção de duplicidade

  • Artigo

Se um aplicativo falhar devido a um erro fatal imediatamente após enviar uma mensagem, e a instância do aplicativo reiniciado erroneamente achar que a entrega da mensagem anterior não ocorreu, um envio subsequente fará com que a mesma mensagem apareça no sistema duas vezes.

Também é possível ocorrer um erro no nível do cliente ou da rede um momento antes e para uma mensagem enviada ser confirmada na fila, com a confirmação não retornando de forma bem sucedida para o cliente. Este cenário deixa o cliente em dúvida quanto ao resultado da operação de envio.

A detecção duplicada elimina a dúvida dessas situações, permitindo que o remetente reenvie a mesma mensagem, e a fila ou o tópico descarta qualquer cópia duplicada.

Observação

A camada básica do Barramento de Serviço do Azure não dá suporte à detecção de duplicidades. As camadas Standard e Premium dão suporte à detecção de duplicidades. Para conferir as diferenças entre essas camadas, consulte preços do Barramento de Serviço.

Como ele funciona

Habilitar a detecção de duplicidades ajuda a controlar a MessageId controlada pelo aplicativo de todas as mensagens enviadas para uma fila ou tópico durante um intervalo especificado. Se qualquer nova mensagem for enviada com MessageId que foi registrada durante a janela de tempo, a mensagem será relatada como aceita (a operação de envio será com êxito), mas a mensagem enviada recentemente será imediatamente ignorada e descartada. Nenhuma outra parte da mensagem além de MessageId é considerada.

O controle de aplicativos do identificador é essencial porque somente isso permite que o aplicativo vincule MessageId a um contexto de processo de negócios, a partir do qual ele poderá ser previsivelmente reconstruído quando ocorrer uma falha.

Para um processo de negócios em que várias mensagens são enviadas no decorrer de tratamento de algum contexto de aplicativo, a MessageId pode ser uma composição do identificador de contexto do nível do aplicativo, como um número de ordem de compra e o assunto da mensagem, por exemplo, 12345.2017/pagamento.

A MessageId sempre pode ser algum GUID, mas a ancoragem o identificador para o processo de negócios produz a repetição previsível, o que é desejado para usar o recurso de detecção de duplicidades com eficiência.

Importante

  • Quando o particionamento está habilitado, MessageId+PartitionKey é usado para determinar a exclusividade. Quando as sessões são habilitadas, a chave de partição e a ID de sessão devem ser as mesmas.
  • Quando o particionamento está desabilitado (padrão), somente MessageId é usado para determinar a exclusividade.
  • Para obter informações sobre SessionId, PartitionKey e MessageId, confira Uso de chaves de partição.
  • Ao usar particionamento e enviar lotes de mensagens, você deve garantir que eles não contenham nenhuma propriedade de identificação de partição. Como a eliminação de duplicação depende da definição explícita de IDs de mensagens para determinar a exclusividade, não é recomendado usar a eliminação de duplicação e envio em lote junto com particionamento.

Observação

As mensagens agendadas são incluídas na detecção de duplicadas. Portanto, se você enviar uma mensagem agendada e depois enviar uma mensagem duplicada não agendada, a mensagem não agendada será descartada. Da mesma forma, se você enviar uma mensagem não agendada e, em seguida, uma mensagem agendada duplicada, a mensagem agendada será descartada.

Tamanho da janela de detecção de duplicidades

Além de habilitar a detecção de duplicatas, você também pode configurar o tamanho da janela de tempo do histórico de detecção de duplicatas durante a qual as IDs das mensagens são retidas. Este valor tem como padrão 10 minutos para filas e tópicos, com um valor mínimo de 20 segundos para o valor máximo de 7 dias.

A habilitação da detecção de duplicatas e o tamanho da janela afetam diretamente o rendimento da fila (e do tópico), pois todas as IDs de mensagens gravadas devem ser comparadas com o identificador de mensagens recém-enviadas.

Manter a janela pequena significa que menos IDs de mensagem devem ser mantidos e correspondidos, e a taxa de transferência é menos impactada. Para entidades de alta taxa de transferência que exigem a detecção de duplicidades, você deve manter a janela o menor possível.

Próximas etapas

Você pode habilitar a detecção de mensagem duplicada usando o portal do Azure, o PowerShell, a CLI, o modelo do ARM, o .NET, o Java, o Python e o JavaScript. Para saber mais, confira Habilitar a detecção de mensagem duplicada.

Em cenários em que o código do cliente não consegue reenviar uma mensagem com a mesma MessageId que antes, é importante criar mensagens que podem ser reprocessadas com segurança. Esta postagem no blog sobre idempotência descreve várias técnicas para fazer isso.

Experimente os exemplos no idioma de sua escolha para explorar os recursos do Barramento de Serviço do Azure.

Consulte os exemplos das bibliotecas de clientes .NET e Java mais antigas aqui:

Em 30 de setembro de 2026, desativaremos as bibliotecas do SDK do Barramento de Serviço do Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, que não estão em conformidade com as diretrizes do SDK do Azure. Também encerraremos o suporte ao protocolo SBMP, portanto, ele não poderá mais ser usado após 30 de setembro de 2026. Antes dessa data, migre para as bibliotecas mais recentes do SDK do Azure, que oferecem atualizações de segurança críticas e funcionalidades aprimoradas.

Embora as bibliotecas mais antigas ainda poderão ser usadas após 30 de setembro de 2026, elas não receberão mais suporte e atualizações oficiais da Microsoft. Para obter mais informações, confira o anúncio de desativação do suporte.