bus di servizio di Azure - Scadenza dei messaggi (ora in tempo reale)

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

La scadenza per qualsiasi 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à scade in corrispondenza dell'ora utc accetta il valore enqueued-time-utctime-to-live + . L'impostazione TTL (time-to-live) su un messaggio broker non viene applicata quando non sono presenti client in ascolto attivo.

Dopo la scadenza dell'istante utc, i messaggi diventano ineligibili 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 può causare la scadenza dei messaggi prima che le applicazioni ricevitori lo ricevano. Prendere in considerazione il TTL più alto che funziona per l'applicazione.

Scadenza a livello di entità

Tutti i messaggi inviati in una coda o in un argomento sono soggetti a una scadenza predefinita impostata a livello di entità. Può anche essere impostato nel portale durante la creazione e la modifica successiva. La scadenza predefinita viene usata per tutti i messaggi inviati all'entità in cui il tempo non è impostato in modo esplicito. La scadenza predefinita funziona anche come limite per il valore time-to-live. I messaggi con scadenza più lunga rispetto al valore predefinito vengono regolati in modo invisibile al valore predefinito del time-to-live del messaggio prima di essere accodato.

Nota

  • Il valore predefinito time-to-live per un messaggio brokerato è il valore più grande possibile per un intero a 64 bit firmato se non specificato in caso contrario.
  • Per le entità di messaggistica (code e argomenti), l'ora di scadenza predefinita è anche il valore più grande possibile per un intero a 64 bit firmato per bus di servizio livelli standard e Premium. Per il livello di base , la scadenza predefinita (anche massima) è di 14 giorni.
  • Se l'argomento specifica una durata 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 usare il portale di Azure. Se l'opzione viene lasciata disabilitata, i messaggi scaduti vengono eliminati. I messaggi scaduti spostati nella coda di lettere non recapitabili possono essere distinti da altri messaggi non recapitati valutando la proprietà motivo della lettera morta archiviata nella sezione proprietà utente.

Se il messaggio è protetto dalla scadenza durante il blocco e se il flag è impostato sull'entità, il messaggio viene spostato nella coda di messaggi non recapitabili perché il blocco viene abbandonato o scade. Tuttavia, non viene spostato se il messaggio viene risolto correttamente, che presuppone che l'applicazione sia stata gestita correttamente, nonostante la scadenza nominale. Per altre informazioni sui blocchi e sulla risoluzione dei messaggi, vedere Trasferimenti di messaggi , blocchi e insediamento.

La combinazione di messaggi non recapitabili e automatici (e transazionali) in scadenza è uno strumento prezioso per stabilire la fiducia in un processo assegnato a un gestore o a un gruppo di gestori sotto una scadenza viene recuperato per l'elaborazione in base alla 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 può elaborare gli elementi 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 impiegherà 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

bus di servizio code, argomenti e 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 dinamicamente e non vengono pulite dopo l'uso, a causa di un'interruzione dell'esecuzione di test o debug. È anche utile quando un'applicazione crea entità dinamiche, ad esempio una coda di risposte, per ricevere risposte in un processo server Web o in un altro oggetto relativamente breve a vita 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à è impostata sulla durata per cui un'entità deve essere inattiva (inutilizzata) prima che venga eliminata automaticamente. Il valore minimo per questa proprietà è di 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àAutoDeleteOnIdle. Se non si vuole che l'entità venga eliminata, impostare la AutoDeleteOnIdle proprietà su DataTime.MaxValue.

Inattività

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

Entità Cosa è 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

SDK

Passaggi successivi

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