Rilevamento duplicati
Se un'applicazione si arresta a causa di un errore irreversibile subito dopo l'invio di un messaggio e l'istanza riavviata dell'applicazione ritiene erroneamente che il recapito del messaggio precedente non sia stato eseguito, il successivo invio provoca la doppia visualizzazione del messaggio nel sistema.
È anche possibile che in un momento precedente si verifichi un errore a livello di client o di rete e che venga eseguito il commit nella coda di un messaggio inviato senza che il client riceva correttamente l'acknowledgement del recapito. Questo scenario lascia il client in dubbio sull'esito dell'operazione di invio.
Il rilevamento dei duplicati consente di evitare queste situazioni, consentendo al mittente di inviare nuovamente lo stesso messaggio che, se duplicato, verrà rimosso automaticamente dalla coda o dall'argomento.
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.
Funzionamento
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
già registrato durante l'intervallo di tempo specificato, il messaggio viene segnalato come accettato (l'operazione di invio ha esito positivo), ma viene immediatamente ignorato ed eliminato. Viene presa in considerazione esclusivamente la parte MessageId
del messaggio.
Il controllo dell'identificatore da parte dell'applicazione è essenziale, perché è solo questo che consente all'applicazione di associare il MessageId
al contesto di un processo di business da cui possa essere ricostruito in modo prevedibile in caso di 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 di business garantisce una ripetibilità prevedibile, necessaria per usare la funzionalità di rilevamento dei duplicati in modo efficace.
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
eMessageId
, vedere Uso delle chiavi di partizione. - Quando si usa il partizionamento e si inviano batch di messaggi, è necessario assicurarsi che non contengano 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 duplicati, è anche possibile configurare la finestra temporale della cronologia di rilevamento duplicati durante la quale vengono conservati gli ID messaggio. Questo valore predefinito è di 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 temporale hanno un impatto diretto sulla velocità effettiva di code e argomenti, dal momento che tutti gli ID messaggio registrati devono essere confrontati con l'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à con velocità effettiva elevata che richiedono il rilevamento dei duplicati, è consigliabile ridurre la finestra al minimo.
Passaggi successivi
È possibile abilitare il rilevamento di messaggi duplicati usando il portale di Azure, PowerShell, l'interfaccia della riga di comando, il modello di Resource Manager, .NET, Java, Python e JavaScript. Per altre informazioni, vedere Abilitare il rilevamento di messaggi duplicati.
Negli scenari in cui il codice client non è in grado di inviare nuovamente un messaggio con lo stesso MessageId di prima, è importante progettare messaggi che possano 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.
- Esempi di libreria client del bus di servizio di Azure per .NET (versione più recente)
- Esempi di libreria client del bus di servizio di Azure per Java (versione più recente)
- Libreria client del bus di servizio di Azure per Python
- Esempi di libreria client del bus di servizio di Azure per JavaScript
- Esempi di libreria client del bus di servizio di Azure per TypeScript
Visualizzare gli esempi per le librerie client .NET e Java precedenti qui:
- Esempi di libreria client del bus di servizio di Azure per .NET (legacy)
- Esempi di libreria client del bus di servizio di Azure per Java (legacy)
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 altre informazioni, vedere l'annuncio del ritiro del supporto.