Sessioni di messaggistica
Le sessioni del bus di servizio di Azure consentono la gestione congiunta e ordinata di sequenze non vincolate di messaggi correlati. Le sessioni possono essere usate in criteri First in, First out (FIFO) e di richiesta-risposta. Questo articolo illustra come usare le sessioni per implementare questi criteri quando si usa il bus di servizio.
Nota
Il livello Basic del bus di servizio non supporta le sessioni. I livelli Standard e Premium supportano le sessioni. Per le differenze tra questi livelli, vedere Prezzi del bus di servizio.
Criterio FIFO (First in, First out)
Per realizzare una garanzia FIFO nell'elaborazione dei messaggi in bus di servizio code o sottoscrizioni, usare sessioni. bus di servizio non è prescrittivo sulla natura della relazione tra i messaggi e non definisce anche un modello specifico per determinare dove inizia o termina una sequenza di messaggi.
Qualsiasi mittente può creare una sessione quando si inviano messaggi in un argomento o in una coda impostando la proprietà ID sessione su un identificatore definito dall'applicazione univoco per la sessione. A livello di protocollo AMQP 1.0 , questo valore esegue il mapping alla proprietà group-id .
Nelle code o nelle sottoscrizioni con riconoscimento della sessione, le sessioni vengono eseguite quando è presente almeno un messaggio con l'ID sessione. Una volta creata una sessione, non c'è un'API o un tempo definito per la scadenza o la rimozione della sessione. Teoricamente, un messaggio può essere ricevuto per una sessione oggi, il messaggio successivo in un anno e se l'ID sessione corrisponde, la sessione è la stessa dal punto di vista bus di servizio.
In genere, tuttavia, un'applicazione riconosce chiaramente dove inizia e dove finisce un set di messaggi correlati, il bus di servizio non imposta alcuna regola specifica. Ad esempio, l'applicazione potrebbe impostare la proprietà Label per il primo messaggio da avviare, per i messaggi intermedi sul contenuto e per l'ultimo messaggio alla fine. La posizione relativa dei messaggi di contenuto può essere calcolata come differenza tra il valore SequenceNumber del messaggio corrente e il valore SequenceNumber del messaggio contrassegnato come start.
Importante
Quando le sessioni sono abilitate in una coda o in una sottoscrizione, le applicazioni client non possono più inviare/ricevere messaggi regolari. Tutti i messaggi devono essere inviati come parte di una sessione (impostando l'ID sessione) e ricevuti accettando la sessione. I client possono comunque visualizzare una coda o una sottoscrizione con sessioni abilitate. Vedere Esplorazione dei messaggi.
Le API per le sessioni sono presenti nei client di accodamento e di sottoscrizione. Esiste un modello imperativo che controlla quando vengono ricevute sessioni e messaggi e un modello basato su gestore che nasconde la complessità della gestione del ciclo di ricezione.
Per gli esempi, usare i collegamenti nella sezione Passaggi successivi .
Funzionalità delle sessioni
Le sessioni forniscono il demultiplexing simultaneo dei flussi di messaggi con interfoliazione, conservando e garantendo il recapito ordinato.
Viene creato un ricevitore di sessione dal client che accetta una sessione. Quando la sessione viene accettata e mantenuta da un client, il client mantiene un blocco esclusivo su tutti i messaggi con l'ID sessione della sessione nella coda o nella sottoscrizione. Conterrà anche blocchi esclusivi su tutti i messaggi con l'ID sessione che arriverà in un secondo momento.
Il blocco viene rilasciato quando si chiamano metodi close sul ricevitore o alla scadenza del blocco. Esistono anche metodi sul ricevitore per rinnovare i blocchi. È invece possibile usare la funzionalità di rinnovo automatico del blocco in cui è possibile specificare la durata per cui si vuole continuare a rinnovare il blocco. Il blocco della sessione deve essere considerato come un blocco esclusivo su un file, vale a dire che l'applicazione deve chiudere la sessione non appena non è più necessaria e/o quando non sono previsti altri messaggi.
Quando più ricevitori simultanei eseguono il pull dalla coda, i messaggi che appartengono a una sessione specifica vengono inviati al ricevitore specifico che attualmente ha bloccato la sessione. Con questa operazione, viene eseguito il demultiplexing di un flusso di messaggi con interfoliazione in una coda o una sottoscrizione in ricevitori diversi, che possono trovarsi anche in computer client diversi, perché la gestione del blocco avviene sul lato del servizio, all'interno del bus di servizio.
L'illustrazione precedente mostra tre ricevitori di sessioni simultanee. Una sessione con SessionId = 4 non ha nessun client proprietario attivo, il che significa che i messaggi non vengono recapitati da questa sessione specifica. Una sessione opera in molti modi, ad esempio come una coda secondaria.
Il blocco di sessione mantenuto dal ricevitore di sessione comprende i blocchi dei messaggi usati dalla modalità di finalizzazione blocco di visualizzazione. Un blocco su una sessione è possibile su un solo ricevitore. Un ricevitore potrebbe avere molti messaggi in anteprima, ma i messaggi vengono ricevuti in ordine. Se un messaggio viene abbandonato, verrà presentato di nuovo con la successiva operazione di ricezione.
Stato della sessione di messaggi
Quando i flussi di lavoro vengono elaborati in sistemi cloud a scalabilità elevata e a disponibilità elevata, il gestore del flusso di lavoro associato a una sessione specifica deve essere in grado di eseguire il ripristino in caso di errori imprevisti e riprendere un lavoro completato parzialmente su un processo o un computer diverso da quello dove il lavoro è stato iniziato.
La funzionalità di stato della sessione consente un'annotazione definita dall'applicazione di una sessione di messaggi all'interno del broker, in modo che lo stato di elaborazione registrato rispetto alla sessione diventi immediatamente disponibile quando la sessione viene acquisita da un nuovo elaboratore.
Dal punto di vista bus di servizio, lo stato della sessione del messaggio è un oggetto binario opaco che può contenere i dati delle dimensioni di un messaggio, ovvero 256 KB per bus di servizio Standard e 100 MB per bus di servizio Premium. Lo stato di elaborazione relativo a una sessione può essere conservato all'interno dello stato della sessione oppure lo stato della sessione può puntare a una posizione di archiviazione o a un record di database che contiene tali informazioni.
I metodi per la gestione dello stato della sessione, SetState e GetState, sono disponibili nell'oggetto ricevitore di sessione. Una sessione che in precedenza non aveva uno stato sessione restituisce un riferimento Null per GetState. Lo stato della sessione impostato in precedenza può essere cancellato passando Null al metodo SetState nel ricevitore.
Lo stato della sessione rimane invariato fino a quando non viene cancellata (restituendo null), anche se sono stati usati tutti i messaggi presenti nella sessione.
Lo stato della sessione conservato in una coda o in una sottoscrizione viene conteggiato per il raggiungimento della quota di archiviazione dell'entità. Quando l'applicazione viene completata con una sessione, è pertanto consigliabile che l'applicazione pulisca lo stato mantenuto per evitare costi di gestione esterni.
Effetti del numero di recapiti
La definizione di numero di recapiti per messaggio nel contesto delle sessioni varia leggermente rispetto alla definizione in assenza di sessioni. Ecco una tabella che riepiloga quando il numero di recapito viene incrementato.
| Scenario | Numero di recapiti del messaggio incrementato |
|---|---|
| La sessione viene accettata, ma il blocco della sessione scade (a causa del timeout) | Sì |
| La sessione viene accettata, i messaggi all'interno della sessione non vengono completati (anche se sono bloccati) e la sessione viene chiusa | No |
| La sessione viene accettata, i messaggi vengono completati e la sessione viene chiusa in modo esplicito | N/D (è il flusso standard. In questo caso, i messaggi vengono rimossi dalla sessione) |
Criterio richiesta-risposta
Il criterio richiesta-risposta è un criterio di integrazione ben definito che consente all'applicazione mittente di inviare una richiesta e offre al ricevitore un modo per inviare correttamente una risposta all'applicazione mittente. Questo criterio richiede in genere un argomento o una coda di breve durata per l'invio di risposte da parte dell'applicazione. In questo scenario, le sessioni offrono una semplice soluzione alternativa con semantica paragonabile.
Più applicazioni possono inviare richieste a una singola coda, con un parametro di intestazione specifico impostato per identificare in modo univoco l'applicazione mittente. L'applicazione ricevente è in grado di elaborare le richieste in arrivo nella coda e di inviare risposte nella coda abilitata per la sessione, impostando l'ID sessione sull'identificatore univoco inviato dal mittente sul messaggio della richiesta. L'applicazione che ha inviato la richiesta può quindi ricevere messaggi sull'ID di sessione specifico ed elaborare correttamente le risposte.
Nota
L'applicazione che invia le richieste iniziali deve conoscere l'ID sessione e usarla per accettare la sessione in modo che la sessione in cui si prevede che la risposta sia bloccata. È consigliabile usare un GUID che identifica in modo univoco l'istanza dell'applicazione come ID sessione. Non deve essere presente alcun gestore di sessione o un timeout specificato nel ricevitore di sessione per la coda per garantire che le risposte siano disponibili per essere bloccate ed elaborate da ricevitori specifici.
Sequenziazione e sessioni
Il numero di sequenza garantisce autonomamente l'ordine di accodamento e l'ordine di estrazione dei messaggi, ma non l'ordine di elaborazione, che richiede sessioni.
Si supponga che nella coda siano presenti tre messaggi e due consumer.
- Il consumer 1 preleva il messaggio 1.
- Il consumer 2 preleva il messaggio 2.
- Il consumer 2 termina l'elaborazione del messaggio 2 e preleva il messaggio 3, mentre consumer 1 non viene ancora eseguito con l'elaborazione del messaggio 1.
- Il consumer 2 termina l'elaborazione del messaggio 3, ma il consumer 1 non viene ancora eseguito con l'elaborazione del messaggio 1.
- Infine, il consumer 1 completa l'elaborazione del messaggio 1.
I messaggi vengono quindi elaborati in questo ordine: messaggio 2, messaggio 3 e messaggio 1. Se è necessario elaborare il messaggio 1, 2 e 3 in ordine, è necessario usare le sessioni.
Se i messaggi devono essere recuperati solo in ordine, non è necessario usare le sessioni. Se i messaggi devono essere elaborati in ordine, usare le sessioni. Lo stesso ID sessione deve essere impostato sui messaggi che appartengono insieme, che possono essere messaggi 1, 4 e 8 in un set e 2, 3 e 6 in un altro set.
Scadenza del messaggio
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. Per altre informazioni, vedere Scadenza dei messaggi.
Passaggi successivi
È possibile abilitare le sessioni di messaggio durante la creazione di una coda usando portale di Azure, PowerShell, interfaccia della riga di comando, modello di Resource Manager, .NET, Java, Python e JavaScript. Per altre informazioni, vedere Abilitare le sessioni di messaggi.
Provare gli esempi nel linguaggio preferito per esplorare bus di servizio di Azure funzionalità.
- .NET
- Java
- Python
- Javascript