Rilevamento dei duplicati in bus di servizio di Azure

Se un'applicazione non riesce a causa di un errore irreversibile immediatamente dopo l'invio di un messaggio e l'istanza dell'applicazione riavviata ritiene erroneamente che il recapito del messaggio precedente non si sia verificato, un invio successivo fa sì che lo stesso messaggio venga visualizzato due volte nel sistema.

È anche possibile che si verifichi un errore a livello di client o di rete un momento prima e che un messaggio inviato venga messo in coda, ma che l'acknowledgment non ritorni correttamente al client. Questo scenario lascia il client in dubbio sull'esito dell'operazione di invio.

Il rilevamento duplicato elimina il dubbio da queste situazioni consentendo al mittente di inviare nuovamente lo stesso messaggio e la coda o l'argomento elimina eventuali copie duplicate.

Funzionamento

Nota

Il livello Basic di bus di servizio non supporta il rilevamento dei duplicati. I livelli Standard e Premium supportano il rilevamento dei duplicati. Per le differenze tra questi livelli, vedere Prezzi del bus di servizio.

Abilitare il rilevamento dei duplicati consente di tenere traccia di MessageId controllato dall'applicazione di tutti i messaggi inviati a una coda o un argomento durante un intervallo di tempo specificato. Se viene inviato un nuovo messaggio con MessageId registrato durante l'intervallo di tempo, bus di servizio segnala il messaggio come accettato (l'operazione di invio ha esito positivo), ma il messaggio appena inviato viene immediatamente ignorato ed eliminato. Viene presa in considerazione esclusivamente la parte MessageId del messaggio.

Il controllo dell'applicazione dell'identificatore è essenziale perché consente all'applicazione di collegare l'oggetto MessageId a un contesto di processo aziendale da cui può essere ricostruito in modo prevedibile quando si verifica un errore.

Per un processo di business in cui vengono inviati più messaggi durante la gestione di un contesto applicazione, il MessageId può essere composto dall'identificatore di contesto a livello di applicazione, ad esempio un numero d'ordine di acquisto, e dall'oggetto del messaggio, ad esempio 12345.2017/pagamento.

Il MessageId può sempre essere un GUID, ma ancorare l'identificatore al processo aziendale garantisce una ripetibilità coerente, fondamentale per utilizzare efficacemente la funzionalità di rilevamento dei duplicati.

Importante

  • Quando il partizionamento è abilitato, MessageId+PartitionKey viene usato per determinare l'univocità. Quando le sessioni sono abilitate, la chiave di partizione e l'ID sessione devono essere uguali.
  • Quando il partizionamento è disabilitato (opzione predefinita), solo MessageId viene usato per determinare l'univocità.
  • Per informazioni su SessionId, PartitionKey e MessageId, vedere Uso delle chiavi di partizione.
  • Quando si usa il partizionamento e si inviano batch di messaggi, assicurarsi che non contengano alcuna proprietà di identificazione della partizione. Poiché la deduplicazione si basa sull'impostazione esplicita degli ID messaggio per determinare l'univocità, non è consigliabile usare la deduplicazione e l'invio in batch insieme al partizionamento.

Nota

I messaggi pianificati sono inclusi nel rilevamento di duplicati. Pertanto, se si invia un messaggio pianificato e quindi si invia un messaggio duplicato non pianificato, il messaggio non pianificato viene eliminato. Analogamente, se si invia un messaggio non pianificato e quindi un messaggio duplicato pianificato, il messaggio pianificato viene eliminato.

Dimensioni della finestra di rilevamento di duplicati

Oltre ad abilitare il rilevamento dei duplicati, è anche possibile configurare le dimensioni dell'intervallo di tempo della cronologia di rilevamento duplicati durante il quale gli ID messaggio vengono conservati. Il valore predefinito è 10 minuti per le code e gli argomenti, con un valore minimo di 20 secondi e un valore massimo di 7 giorni.

L'abilitazione del rilevamento dei duplicati e le dimensioni della finestra hanno un impatto diretto sulla velocità effettiva di code e argomenti, dal momento che tutti gli ID messaggio registrati devono essere abbinati all'identificatore dei nuovi messaggi inviati.

Mantenendo una finestra temporale di dimensioni ridotte, occorre conservare e confrontare un numero inferiore di ID messaggio, con un minore impatto sulla velocità effettiva. Per le entità ad alto throughput che richiedono il rilevamento dei duplicati, mantenere la finestra il più piccola possibile.

Passaggi successivi

È possibile abilitare il rilevamento di messaggi duplicati usando il portale di Azure, PowerShell, l'interfaccia della riga di comando, Resource Manager modello, .NET, Java, Python e JavaScript. Per altre informazioni, vedere Abilitare il rilevamento di messaggi duplicati.

Negli scenari in cui il codice client non può inviare nuovamente un messaggio con lo stesso MessageId di prima, progettare messaggi che possono essere rielaborati in modo sicuro. Questo post di blog sull'idempotenza descrive varie tecniche per eseguire questa operazione.

Provare gli esempi nel linguaggio preferito per esplorare le funzionalità del bus di servizio di Azure.

Visualizzare gli esempi per le librerie client .NET e Java precedenti qui:

Il 30 settembre 2026 verranno ritirate le librerie dell'SDK del bus di servizio di Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, che non sono conformi alle linee guida di Azure SDK. Verrà terminato anche il supporto del protocollo SBMP, quindi non sarà più possibile usare questo protocollo dopo il 30 settembre 2026. Eseguire la migrazione alle librerie più recenti di Azure SDK, che offrono aggiornamenti critici della sicurezza e funzionalità migliorate, prima di tale data.

Anche se le librerie precedenti possono ancora essere usate oltre il 30 settembre 2026, non riceveranno più il supporto e gli aggiornamenti ufficiali da Microsoft. Per ulteriori informazioni, consultare l'annuncio relativo all'interruzione del supporto.

  • Last updated on