Condividi tramite

Bus di servizio di Azure - Scadenza messaggi (durata)

  • Articolo

Il payload all'interno di un messaggio, oppure di un comando o di una richiesta che un messaggio trasmette a un ricevitore, è quasi sempre soggetto a un qualche tipo di scadenza a livello di applicazione. Dopo tale scadenza, il contenuto non viene più recapitato oppure l'operazione richiesta non viene più eseguita.

Per gli ambienti di sviluppo e test in cui code e argomenti vengono spesso usati nel contesto di esecuzioni parziali di applicazioni o parti di applicazioni, è anche consigliabile che i messaggi di test abbandonati vengano automaticamente sottoposti a Garbage Collection, in modo che l'esecuzione dei test successiva possa iniziare in modo pulito.

Nota

Se non si ha ancora familiarità con i concetti relativi al bus di servizio, vedere Concetti relativi al bus di servizio e Code, argomenti e sottoscrizioni del bus di servizio.

La scadenza dei singoli messaggi può essere controllata impostando la proprietà di sistema time-to-live, che specifica una durata relativa. La scadenza diventa un istante assoluto quando il messaggio viene accodato nell'entità. In quel momento, la proprietà expires-at-utc acquisisce il valore enqueued-time-utc + time-to-live. L'impostazione TTL (time-to-live) di un messaggio negoziato non viene applicata se non sono presenti client attivamente in ascolto.

Nota

I messaggi scaduti potrebbero non essere rimossi immediatamente dal broker. Il broker può scegliere di scadere in modo differire questi messaggi, in base al fatto che l'entità sia in uso attivo al momento della scadenza di un messaggio. Di conseguenza, i clienti potrebbero osservare un numero di messaggi non corretto quando si usa la scadenza del messaggio e potrebbero anche visualizzare questi messaggi durante un'operazione di visualizzazione. Tuttavia, quando si ricevono messaggi, il messaggio scaduto non verrà incluso.

Dopo l'istante definito da expires-at-utc, i messaggi non sono più idonei per il recupero. La scadenza non influisce sui messaggi attualmente bloccati per il recapito. Tali messaggi vengono comunque gestiti normalmente. Se il blocco scade o il messaggio viene abbandonato, la scadenza ha effetto immediato. Quando il messaggio è bloccato, l'applicazione potrebbe essere in possesso di un messaggio che è scaduto. Il fatto che l'applicazione proceda con l'elaborazione o scelga di abbandonare il messaggio dipende dall'implementatore.

Una durata (TTL) estremamente bassa nell'ordine di millisecondi o secondi potrebbe causare la scadenza dei messaggi prima che le applicazioni ricevitori lo ricevano. Prendere in considerazione il valore TTL più elevato che funziona per l'applicazione.

Nota

Per i messaggi pianificati, specificare l'ora di accodamento in cui si vuole che il messaggio compaia nella coda per il recupero. L'ora in cui il messaggio viene inviato al bus di servizio è diversa dal momento in cui il messaggio viene accodato. L'ora di scadenza del messaggio dipende dall'ora di accodamento, non dal momento in cui il messaggio viene inviato al bus di servizio. Il valore expires-at-utc è quindi ancora ora di accodamento + TTL.

Ad esempio, se si imposta ScheduledEnqueueTimeUtc su 5 minuti da UtcNow e TimeToLive su 10 minuti, il messaggio scadrà dopo 5 + 10 = 15 minuti da ora. Il messaggio compare nella coda dopo 5 minuti e il contatore di 10 minuti inizia da quel momento.

Scadenza a livello di entità

Tutti i messaggi inviati in una coda o un argomento sono soggetti a una scadenza predefinita impostata a livello di entità. Può anche essere impostata nel portale durante la creazione e modificata in un secondo momento. La scadenza predefinita viene usata per tutti i messaggi inviati all'entità in cui la durata non è impostata in modo esplicito. La scadenza predefinita funge anche da limite massimo per il valore time-to-live. I messaggi con un valore della scadenza time-to-live superiore rispetto al valore predefinito vengono modificati automaticamente impostando il valore time-to-live del messaggio predefinito prima di essere accodati.

La scadenza alle ore utc è per impostazione predefinita. Se la durata (TTL) del messaggio non è impostata e solo l'entità TTL è impostata, expires-at-utc è un valore calcolato e non viene calcolato nel percorso Visualizza ma viene calcolato nel percorso Receive/Peeklock. Se il messaggio ha una durata (TTL), questa scadenza viene calcolata all'ora utc al momento dell'invio e dell'archiviazione del messaggio. In questo caso, in questo caso Peek restituirà la scadenza corretta dei valori at-utc .

Nota

  • Il valore time-to-live predefinito per un messaggio negoziato è il valore massimo possibile per un intero con segno a 64 bit, se non specificato diversamente.
  • Per le entità di messaggistica (code e argomenti), l'ora di scadenza predefinita è anche il valore massimo possibile per un intero a 64 bit con segno per livelli Standard e Premium del bus di servizio. Per il livello Basic, la scadenza predefinita (anche massima) è 14 giorni.
  • Se l'argomento specifica una durata (TTL) inferiore rispetto alla sottoscrizione, viene applicata la durata dell'argomento.

I messaggi scaduti possono essere spostati facoltativamente in una coda di messaggi non recapitabili. È possibile configurare questa impostazione a livello di codice o usando il portale di Azure. Se l'opzione viene lasciata disabilitata, i messaggi scaduti vengono eliminati. I messaggi scaduti spostati nella coda di messaggi non recapitabili possono essere distinti dagli altri messaggi della coda di messaggi non recapitabili valutando la proprietà dead-letter reason che il broker archivia nella sezione delle proprietà utente.

Il messaggio è protetto da scadenza fino a quando è bloccato e se il flag è impostato sull'entità. Il messaggio viene spostato nella coda di messaggi non recapitabili non appena il blocco viene abbandonato o scade. Non viene tuttavia spostato se il messaggio viene finalizzato correttamente, operazione che presuppone che l'applicazione lo abbia gestito correttamente nonostante la scadenza nominale. Per altre informazioni sui blocchi e sulla finalizzazione dei messaggi, vedere Trasferimenti, blocchi e finalizzazione dei messaggi.

La combinazione di durata (TTL) e inserimento automatico (e transazionale) nella coda di messaggi non recapitabili alla scadenza rappresenta uno strumento prezioso per stabilire in modo affidabile se un processo assegnato a un gestore o a un gruppo di gestori con una determinata scadenza viene recuperato per l'elaborazione quando la scadenza viene raggiunta.

Si consideri, ad esempio, un sito Web che deve eseguire in modo affidabile i processi in un back-end con vincoli di scalabilità e che in alcuni casi è soggetto a picchi di traffico o richiede un isolamento rispetto a episodi di disponibilità di tale back-end. In una situazione normale, il gestore sul lato server per i dati utente inviati esegue il push delle informazioni in una coda e successivamente riceve una risposta che conferma la corretta gestione della transazione in una coda di risposta. Se c'è un picco di traffico e il gestore di back-end non è in grado di elaborare gli elementi del backlog in tempo, i processi scaduti vengono restituiti nella coda di messaggi non recapitabili. L'utente interattivo può ricevere una notifica che indica che l'operazione richiesta impiega un po' più tempo del solito e la richiesta può quindi essere inserita in un'altra coda per un percorso di elaborazione in cui il risultato dell'elaborazione finale viene inviato all'utente tramite posta elettronica.

Entità temporanee

È possibile creare sottoscrizioni, argomenti e code del bus di servizio come entità temporanee, che vengono rimosse automaticamente se non vengono usate per un periodo di tempo specificato.

La pulizia automatica è utile negli scenari di sviluppo e test in cui le entità vengono create in modo dinamico e non vengono eliminate dopo l'uso, a causa di un'interruzione dell'esecuzione dei test o del debug. È utile anche quando un'applicazione crea entità dinamiche, ad esempio una coda di risposta, per la ricezione di risposte in un processo del server Web o in un altro oggetto di durata relativamente breve, in cui è difficile eseguire la pulizia delle entità in modo affidabile quando l'istanza dell'oggetto non è più presente.

La funzionalità è abilitata usando l'eliminazione automatica sulla proprietà inattiva nell'entità. Questa proprietà deve essere impostata sulla durata per cui l'entità deve rimanere inattiva (non usata) prima di essere eliminata automaticamente. Il valore minimo per questa proprietà è 5 minuti.

Importante

L'impostazione del livello di blocco di Azure Resource Manager su CanNotDelete, nello spazio dei nomi o a un livello superiore, non impedisce l'eliminazione delle entità con AutoDeleteOnIdle. Se non si vuole eliminare l'entità, impostare la proprietà AutoDeleteOnIdle su DataTime.MaxValue.

Inattività

Ecco cosa identifica le entità (code, argomenti e sottoscrizioni) come inattive:

Entità Che cosa viene considerato inattivo
Queue
  • Nessun invio
  • Nessuna ricezione
  • Nessun aggiornamento alla coda
  • Nessun messaggio pianificato
  • Nessuna esplorazione/visualizzazione
Argomento
  • Nessun invio
  • Nessun aggiornamento all'argomento
  • Nessun messaggio pianificato
  • Nessuna operazione sulle sottoscrizioni dell'argomento (vedere la riga successiva)
Abbonamento
  • Nessuna ricezione
  • Nessun aggiornamento alla sottoscrizione
  • Nessuna nuova regola aggiunta alla sottoscrizione
  • Nessuna esplorazione/visualizzazione

Importante

Se è stato configurato l'inoltro automatico nella coda o nella sottoscrizione, ciò equivale ad avere un ricevente che esegue ricezioni nella coda o nella sottoscrizione e tali elementi non saranno quindi inattivi.

SDK

Passaggi successivi

Per altre informazioni sulla messaggistica del bus di servizio, vedere gli articoli seguenti: