Condividi tramite

Sessioni di messaggistica

Le sessioni del bus di servizio di Azure consentono l'elaborazione congiunta e ordinata di sequenze non associate di messaggi correlati. Le sessioni possono essere usate nei modelli primo entrato, primo uscito (FIFO) e di richiesta-risposta. Questo articolo illustra come usare le sessioni per implementare questi modelli quando si usa il bus di servizio.

Annotazioni

Il livello Basic del bus di servizio non supporta le sessioni. I livelli Standard e Premium supportano sessioni. Per le differenze tra questi livelli, vedere Prezzi del bus di servizio.

Modello Primo ad entrare, primo ad uscire (FIFO)

Per ottenere l'elaborazione FIFO nell'elaborazione dei messaggi dalle code o dalle sottoscrizioni del bus di servizio, usare le sessioni. Il 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.

Un mittente può avviare una sessione quando si inviano messaggi in un argomento o in una coda impostando la proprietà ID sessione su identificatore univoco definito dall'applicazione. A livello di protocollo AMQP 1.0 , questo valore esegue il mapping alla proprietà group-id .

Nelle code o sottoscrizioni con supporto per le sessioni, le sessioni si creano quando è presente almeno un messaggio con l'ID sessione. Dopo l'esistenza di una sessione, non esiste un'ora o un'API definita per quando la sessione scade o scompare. 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 del bus di servizio.

In genere, tuttavia, un'applicazione definisce dove inizia e termina un set di messaggi correlati. Il bus di servizio non impone regole specifiche. Ad esempio, l'applicazione potrebbe impostare la proprietà Label per il primo messaggio come inizio, per i messaggi intermedi come contenuto e per l'ultimo messaggio alla fine. La posizione relativa dei messaggi di contenuto può essere calcolata come la differenza di SequenceNumber del messaggio corrente rispetto al messaggio inizialeSequenceNumber.

Importante

Quando le sessioni sono abilitate in una coda o in una sottoscrizione, le applicazioni client non possono più inviare/ricevere messaggi regolari. I client devono inviare messaggi come parte di una sessione impostando l'ID sessione e ricevono accettando la sessione. I client potrebbero comunque visualizzare una coda o una sottoscrizione con sessioni abilitate. Vedere Esplorazione dei messaggi.

Le API per le sessioni esistono nei client di coda e sottoscrizione. Esistono due modi per ricevere sessioni e messaggi: il modello imperativo, in cui si controlla manualmente quando e come vengono ricevuti i messaggi e il modello basato sul gestore, che semplifica automaticamente la gestione e l'elaborazione del ciclo di messaggi.

Per esempi, usare i collegamenti nella sezione Esempi .

Funzionalità della sessione

Le sessioni forniscono un demultiplexing simultaneo dei flussi di messaggi intrecciati, pur mantenendo e garantendo il recapito ordinato.

Diagramma che mostra come la funzione Sessioni mantiene una consegna ordinata.

Un client crea un ricevitore di sessione per accettare una sessione. Quando il client accetta e detiene una sessione, mantiene un blocco esclusivo su tutti i messaggi con l'ID sessione di quella sessione nella coda o nell'abbonamento. Detiene blocchi esclusivi su tutti i messaggi con l'ID sessione che arrivano in un secondo momento.

Il blocco viene rilasciato quando si chiamano i metodi di chiusura sul ricevitore o quando il blocco scade. 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 di sessione deve essere considerato come un blocco esclusivo in un file, ovvero l'applicazione deve chiudere la sessione non appena non è più necessaria e/o non prevede 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 tale operazione, un flusso di messaggi intercalato in una coda o una sottoscrizione viene pulitamente demultiplexato a diversi ricevitori e tali ricevitori possono anche risiedere su diversi computer client, poiché la gestione dei blocchi avviene lato servizio, all'interno del Bus di Servizio.

La figura precedente mostra tre ricevitori di sessione simultanei. Una sessione con SessionId = 4 non dispone di un client attivo proprietario, il che significa che non vengono recapitati messaggi da questa sessione specifica. Una sessione funziona in molti modi simile a una coda secondaria.

Il blocco di sessione mantenuto dal ricevitore di sessione è un ombrello per i blocchi di messaggio usati dalla modalità di conferma del peek-lock. Un solo ricevitore può avere un blocco su una sessione. Un ricevitore potrebbe avere molti messaggi in transito, ma i messaggi vengono ricevuti in ordine. Se si abbandona un messaggio, lo stesso messaggio viene nuovamente servito con l'operazione di ricezione successiva.

Stato della sessione del messaggio

Quando i flussi di lavoro vengono elaborati in sistemi cloud a disponibilità elevata e su larga scala, il gestore del flusso di lavoro associato a una determinata sessione deve essere in grado di eseguire il ripristino da errori imprevisti e può riprendere il lavoro parzialmente completato in un processo o in un computer diverso da cui è iniziato il lavoro.

La funzionalità dello stato della sessione consente un'annotazione definita dall'applicazione di una sessione di messaggio all'interno del broker, in modo che lo stato di elaborazione registrato relativo a tale sessione diventi immediatamente disponibile quando la sessione viene acquisita da un nuovo processore.

Dal punto di vista del 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 il bus di servizio Standard e 100 MB per Il bus di servizio Premium. Lo stato di elaborazione relativo a una sessione può essere mantenuto all'interno dello stato della sessione oppure lo stato della sessione può puntare a un percorso di archiviazione o a un record di database che contiene tali informazioni.

I metodi per la gestione dello stato della sessione, SetState, e GetStatesono 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 sul SetState ricevitore.

Lo stato della sessione rimane finché non viene cancellato (restituendo Null), anche se vengono utilizzati tutti i messaggi in una sessione.

Lo stato della sessione mantenuto in una coda o in una sottoscrizione viene considerato nel calcolo della quota di archiviazione di quella entità. Quando l'applicazione termina una sessione, è pertanto consigliabile che l'applicazione pulisca lo stato memorizzato per evitare di incorrere in costi di gestione esterni.

Impatto del conteggio delle consegne

La definizione del numero di recapito 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.

Sceneggiatura Il conteggio delle consegne del messaggio è stato 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 modello request-reply è un modello di integrazione ben definito che consente all'applicazione mittente di inviare una richiesta e consente al ricevitore di inviare correttamente una risposta all'applicazione mittente. Questo modello richiede in genere una coda o un argomento di breve durata per l'applicazione a cui inviare risposte. In questo scenario, le sessioni offrono una soluzione alternativa semplice con semantica paragonabile.

Più applicazioni possono inviare le richieste a una singola coda di richieste, con un parametro di intestazione specifico impostato per identificare in modo univoco l'applicazione mittente. L'applicazione ricevitore può elaborare le richieste in arrivo nella coda e inviare risposte nella coda abilitata per la sessione, impostando l'ID sessione sull'identificatore univoco inviato dal mittente nel messaggio di richiesta. L'applicazione che ha inviato la richiesta può quindi ricevere messaggi sull'ID sessione specifico ed elaborare correttamente le risposte.

Annotazioni

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 aspetta 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.

Diciamo che nella coda ci sono tre messaggi e due consumatori.

  1. Il consumer 1 preleva il messaggio 1.
  2. Il consumer 2 preleva il messaggio 2.
  3. Il Consumatore 2 termina l'elaborazione del messaggio 2 e preleva il messaggio 3, mentre il Consumatore 1 non ha ancora finito con l'elaborazione del messaggio 1.
  4. Il consumatore 2 termina l'elaborazione del messaggio 3, ma il consumatore 1 non ha ancora terminato l'elaborazione del messaggio 1.
  5. 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 il tempo di vita (TTL) di uno qualsiasi dei messaggi scade, tutti i messaggi correlati a quella sessione vengono eliminati o segnalati come non recapitabili in base all'impostazione di scadenza per messaggi non recapitabili attivata 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.

Esempi

È possibile abilitare le sessioni di messaggi durante la creazione di una coda 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 le sessioni di messaggi.

Provare gli esempi nel linguaggio preferito per esplorare le funzionalità del bus di servizio di Azure.

Contenuti correlati