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 di bus di servizio, vedere bus di servizio concetti e bus di servizio code, argomenti e sottoscrizioni.

La scadenza di un singolo messaggio 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 assume il valore accodato-time-utc + time-to-live. L'impostazione TTL (Time-to-Live) in un messaggio negoziato non viene applicata quando non sono presenti client in ascolto attivo.

Dopo l'istante scaduto alle ore utc , i messaggi diventano non 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.

Il TTL estremamente basso 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 desidera che il messaggio materializzi nella coda per il recupero. L'ora in cui il messaggio viene inviato a bus di servizio è diverso dal momento in cui il messaggio viene accodato. L'ora di scadenza del messaggio dipende dall'ora accodata, non dal momento in cui il messaggio viene inviato a bus di servizio. Pertanto, la scadenza alle ore-utc è ancora tempo accodato + tempo in tempo reale.

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

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 impostato nel portale durante la creazione e modificato 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 funziona anche come limite massimo per il valore time-to-live. I messaggi con scadenza più lunga rispetto al valore predefinito vengono regolati automaticamente sul valore predefinito per la durata del messaggio prima di essere accodati.

Nota

  • Il valore predefinito time-to-live 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 bus di servizio livelli Standard e Premium. Per il livello basic , la scadenza predefinita (anche massima) è di 14 giorni.
  • Se l'argomento specifica un valore TTL inferiore rispetto alla sottoscrizione, viene applicato il TTL 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 usare il portale di Azure. Se l'opzione viene lasciata disabilitata, i messaggi scaduti vengono eliminati. I messaggi scaduti spostati nella coda dei messaggi non recapitabili possono essere distinti da altri messaggi non recapitabili valutando la proprietà reason dei messaggi non recapitabili archiviata dal broker nella sezione delle proprietà utente.

Se il messaggio è protetto dalla scadenza durante il blocco e se il flag è impostato sull'entità, il messaggio viene spostato nella coda dei messaggi non recapitabili quando il blocco viene abbandonato o scade. Tuttavia, non viene spostato se il messaggio viene stabilito correttamente, che quindi presuppone che l'applicazione l'abbia gestita correttamente, nonostante la scadenza nominale. Per altre informazioni sui blocchi e sulla liquidazione dei messaggi, vedere Trasferimenti, blocchi e liquidazione dei messaggi.

La combinazione di messaggi non recapitabili time-to-live e automatici (e transazionali) in scadenza è uno strumento prezioso per stabilire se un processo assegnato a un gestore o un gruppo di gestori in base a una scadenza viene recuperato per l'elaborazione quando viene raggiunta la scadenza.

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 si verifica un picco di traffico e il gestore back-end non è in grado di elaborare gli elementi di backlog nel tempo, i processi scaduti vengono restituiti nella coda dei messaggi non recapitabili. L'utente interattivo può ricevere una notifica che l'operazione richiesta richiede più tempo del solito e la richiesta può quindi essere inserita in una coda diversa per un percorso di elaborazione in cui il risultato dell'elaborazione finale viene inviato all'utente tramite posta elettronica.

Scadenza per le entità abilitate per la sessione

Per le code abilitate per la sessione o le sottoscrizioni degli argomenti, i messaggi vengono bloccati a livello di sessione. Se la durata (TTL) per uno qualsiasi dei messaggi scade, tutti i messaggi correlati a tale sessione vengono eliminati o non recapitabili in base all'impostazione di scadenza della messaggistica abilitata per la scadenza della messaggistica sull'entità. In altre parole, se nella sessione è presente un singolo messaggio che ha superato il TTL, tutti i messaggi nella sessione sono scaduti. I messaggi scadono solo se è presente un listener attivo.

Entità temporanee

bus di servizio le code, gli argomenti e le sottoscrizioni possono essere create come entità temporanee, che vengono rimosse automaticamente quando non sono state 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 pulite dopo l'uso, a causa di un'interruzione dell'esecuzione del test o del debug. È utile anche quando un'applicazione crea entità dinamiche, ad esempio una coda di risposte, per la ricezione di risposte in un processo del server Web o in un altro oggetto di breve durata relativamente breve, in cui è difficile pulire in modo affidabile tali entità quando l'istanza dell'oggetto scompare.

La funzionalità è abilitata usando l'eliminazione automatica sulla proprietà inattiva nello spazio dei nomi . Questa proprietà viene impostata sulla durata per cui un'entità deve essere inattiva (inutilizzata) prima che venga 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 AutoDeleteOnIdle proprietà su DataTime.MaxValue.

Inattività

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

Entità Cosa viene considerato inattiva
Coda
  • 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)
Subscription
  • Nessuna ricezione
  • Nessun aggiornamento alla sottoscrizione
  • Nessuna nuova regola aggiunta alla sottoscrizione
  • Nessuna esplorazione/visualizzazione

Importante

Se è stata configurata l'inoltro automatico nella coda o nella sottoscrizione, equivale a ricevere una maschera ricevente nella coda o nella sottoscrizione e non saranno inattive.

SDK

Passaggi successivi

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