Elaborare un set di messaggi correlati in un ordine definito, senza bloccare l'elaborazione di altri gruppi di messaggi.
Contesto e problema
Le applicazioni spesso devono elaborare una sequenza di messaggi nell'ordine in cui arrivano, pur essendo ancora in grado di aumentare il carico. In un'architettura distribuita, l'elaborazione di questi messaggi in ordine non è semplice, perché i lavoratori possono ridimensionare in modo indipendente e spesso eseguire il pull dei messaggi in modo indipendente, usando un modello Consumer concorrenti.
Ad esempio, un sistema di rilevamento ordini riceve un ledger contenente ordini e le operazioni pertinenti su tali ordini. Queste operazioni possono essere per creare un ordine, aggiungere una transazione all'ordine, modificare una transazione precedente o eliminare un ordine. In questo sistema, le operazioni devono essere eseguite in modo first-in-first-out (FIFO), ma solo a livello di ordine. Tuttavia, la coda iniziale riceve un ledger contenente transazioni per molti ordini, che possono essere interleaved.
Soluzione
Eseguire il push di messaggi correlati in categorie all'interno del sistema di accodamento e avere il blocco dei listener della coda e il pull solo da una categoria, un messaggio alla volta.
Di seguito è riportato il modello sequenziale generale simile al seguente:
Nella coda i messaggi per categorie diverse possono essere interleavedi, come illustrato nel diagramma seguente:
Considerazioni e problemi
Prima di decidere come implementare questo modello, considerare quanto segue:
- Unità categoria/scala. Quale proprietà dei messaggi in ingresso è possibile aumentare? Nello scenario di rilevamento degli ordini, questa proprietà è l'ID ordine.
- Velocità effettiva. Qual è la velocità effettiva dei messaggi di destinazione? Se è molto alto, potrebbe essere necessario riconsiderare i requisiti FIFO. Ad esempio, è possibile applicare un messaggio di inizio/fine, ordinare in base al tempo, quindi inviare un batch per l'elaborazione?
- Funzionalità del servizio. La scelta del bus di messaggi consente l'elaborazione one-a-time dei messaggi all'interno di una coda o di una categoria di una coda?
- Evolvability. Come aggiungere una nuova categoria di messaggi al sistema? Si supponga, ad esempio, che il sistema ledger descritto in precedenza sia specifico di un cliente. Se è necessario eseguire l'onboarding di un nuovo cliente, è possibile disporre di un set di processori ledger che distribuiscono il lavoro per ID cliente?
- È possibile che i consumer possano ricevere un messaggio non in ordine, a causa della latenza di rete variabile durante l'invio di messaggi. È consigliabile usare i numeri di sequenza per verificare l'ordinamento. È anche possibile includere un flag speciale "fine della sequenza" nell'ultimo messaggio di una transazione. Le tecnologie di elaborazione di flusso, ad esempio Spark o Analisi di flusso di Azure, possono elaborare i messaggi in ordine entro un intervallo di tempo.
Quando usare questo modello
Usare questo modello quando:
- Si hanno messaggi che arrivano in ordine e devono essere elaborati nello stesso ordine.
- L'arrivo dei messaggi è o può essere "classificato" in modo che la categoria diventi un'unità di scala per il sistema.
Questo modello potrebbe non essere adatto per:
- Scenari di velocità effettiva estremamente elevati (milioni di messaggi/minuti o secondo), poiché il requisito FIFO limita la scalabilità che può essere eseguita dal sistema.
Esempio
In Azure questo modello può essere implementato usando le sessioni di messaggio bus di servizio di Azure. Per i consumer, è possibile usare App per la logica con il connettore di blocco del bus di servizio o Funzioni di Azure con il trigger del bus di servizio.
Per l'esempio di rilevamento degli ordini precedente, elaborare ogni messaggio di ledger nell'ordine ricevuto e inviare ogni transazione a un'altra coda in cui la categoria è impostata sull'ID ordine. Una transazione non si estenderà mai su più ordini in questo scenario, quindi i consumer elaborano ogni categoria in parallelo ma FIFO all'interno della categoria.
Il processore di sporgenza rimuove i messaggi de-batching del contenuto di ogni messaggio nella prima coda:
Il processore ledger si occupa di:
- Camminare il ledger una transazione alla volta.
- Impostazione dell'ID sessione del messaggio in modo che corrisponda all'ID ordine.
- Invio di ogni transazione ledger a una coda secondaria con l'ID sessione impostato sull'ID ordine.
I consumer ascoltano la coda secondaria in cui elaborano tutti i messaggi con ID ordine corrispondenti in ordine dalla coda. I consumer usano la modalità peek-lock .
Quando si considera la scalabilità, la coda del ledger è un collo di bottiglia primario. Le diverse transazioni inviate al ledger potrebbero fare riferimento allo stesso ID ordine. Tuttavia, i messaggi possono essere visualizzati dopo il ledger al numero di ordini in un ambiente serverless.
Passaggi successivi
Per l'implementazione di questo modello possono risultare utili anche le informazioni seguenti: