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. Usare le sessioni in primo entrato, primo uscito (FIFO) e nei modelli 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 durante l'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 nelle sottoscrizioni in grado di riconoscere le sessioni, queste vengono create quando c'è 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 differenza tra il valore SequenceNumber del messaggio corrente e il valore SequenceNumber del messaggio contrassegnato come start.

Importante

Quando si abilitano le sessioni in una coda o in una sottoscrizione, le applicazioni client non possono più inviare o ricevere messaggi regolari. I client devono inviare messaggi come parte di una sessione impostando l'ID sessione e ricevere messaggi accettando la sessione. I client possono comunque visualizzare una coda o una sottoscrizione con sessioni abilitate. Per altre informazioni, 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 il demultiplexing simultaneo dei flussi di messaggi con interfoliazione, conservando 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 la sessione viene accettata e mantenuta da un client, quest'ultimo mantiene un blocco esclusivo su tutti i messaggi con l'ID della sessione nella coda o nella sottoscrizione. Detiene blocchi esclusivi su tutti i messaggi con l'ID della 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. Il ricevitore dispone anche di metodi per rinnovare i blocchi. Invece di usare questi metodi, è possibile usare la funzionalità di rinnovo automatico del blocco in cui si specifica la durata per cui si vuole continuare a rinnovare il blocco. Considerare il blocco di sessione come un blocco esclusivo su un file, ovvero che l'applicazione deve chiudere la sessione non appena non è più necessaria 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. Usando tale operazione, un flusso di messaggi intrecciato in una coda o una sottoscrizione viene demultiplexato in modo ordinato verso ricevitori diversi. Questi ricevitori possono anche essere ospitati su diversi computer client, poiché la gestione dei blocchi avviene sul lato servizio, all'interno di Service Bus.

La figura precedente mostra tre ricevitori di sessione simultanei. Una sessione con SessionId = 4 non ha 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 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 transito, ma i messaggi vengono ricevuti in ordine. Se si abbandona un messaggio, lo stesso messaggio viene nuovamente servito dall'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 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.

L'oggetto ricevitore di sessione ha i metodi per la gestione dello stato SetState della sessione e GetState. 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 conservato in una coda o in una sottoscrizione viene conteggiato per il raggiungimento della quota di archiviazione dell'entità. Al termine di una sessione, l'applicazione deve pulire lo stato mantenuto per evitare 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 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 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. Usare un GUID che identifica in modo univoco l'istanza dell'applicazione come ID di sessione. Per assicurarsi che le risposte siano disponibili per essere bloccate ed elaborate da ricevitori specifici, la coda non deve avere alcun gestore di sessione o un timeout specificato nel ricevitore della sessione.

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.

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

  1. Il consumatore 1 riceve il messaggio 1.
  2. Il consumatore 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. Impostare lo stesso ID sessione per i 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 time-to-live (TTL) per uno dei messaggi scade, il sistema elimina o non recapita tutti i messaggi correlati a tale sessione in base all'impostazione di scadenza della messaggistica abilitata per la scadenza della messaggistica sull'entità. In altre parole, se è presente un singolo messaggio nella sessione che supera il TTL, tutti i messaggi nella sessione scadono. 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

  • Last updated on