Bearbeta en uppsättning relaterade meddelanden i en definierad ordning, utan att blockera bearbetningen av andra grupper av meddelanden.
Kontext och problem
Program behöver ofta bearbeta en sekvens med meddelanden i den ordning de anländer, samtidigt som de kan skala ut för att hantera ökad belastning. I en distribuerad arkitektur är det inte enkelt att bearbeta dessa meddelanden i ordning, eftersom arbetarna kan skala oberoende av varandra och ofta hämta meddelanden oberoende av varandra, med hjälp av ett mönster för konkurrerande konsumenter.
Ett orderspårningssystem tar till exempel emot en transaktionsbok som innehåller order och relevanta åtgärder för dessa beställningar. Dessa åtgärder kan vara att skapa en order, lägga till en transaktion i ordern, ändra en tidigare transaktion eller ta bort en order. I det här systemet måste åtgärder utföras på fifo-sätt (först in först ut), men bara på ordernivå. Den första kön tar dock emot ett transaktionsregister som innehåller transaktioner för många beställningar, som kan interfolieras.
Lösning
Skicka relaterade meddelanden till kategorier i kösystemet och låt kölyssnare låsa och hämta endast från en kategori, ett meddelande i taget.
Så här ser det allmänna mönstret sekventiell konvoj ut:
I kön kan meddelanden för olika kategorier interfolieras, enligt följande diagram:
Problem och överväganden
Tänk på följande när du bestämmer hur du ska implementera mönstret:
- Kategori/skalningsenhet. Vilken egenskap för dina inkommande meddelanden kan du skala ut på? I scenariot för orderspårning är den här egenskapen order-ID:t.
- Dataflöde. Vad är ditt dataflöde för målmeddelande? Om den är mycket hög kan du behöva tänka över dina FIFO-krav. Kan du till exempel framtvinga ett start-/slutmeddelande, sortera efter tid och sedan skicka en batch för bearbetning?
- Tjänstfunktioner. Tillåter ditt val av meddelandebuss en-i-en-tid-bearbetning av meddelanden i en kö eller kategori i en kö?
- Utvecklingsbarhet. Hur lägger du till en ny kategori av meddelanden i systemet? Anta till exempel att transaktionssystemet som beskrivs ovan är en specifik kund. Om du behövde registrera en ny kund kan du ha en uppsättning transaktionsregisterprocessorer som distribuerar arbete per kund-ID?
- Det är möjligt att konsumenter kan få ett meddelande i fel ordning på grund av varierande nätverksfördröjning när de skickar meddelanden. Överväg att använda sekvensnummer för att verifiera ordningen. Du kan också inkludera en särskild "end of sequence"-flagga i det sista meddelandet i en transaktion. Dataströmbearbetningstekniker som Spark eller Azure Stream Analytics kan bearbeta meddelanden i ordning inom ett tidsfönster.
När du ska använda det här mönstret
Använd det här mönstret i sådana här scenarier:
- Du har meddelanden som kommer i ordning och måste bearbetas i samma ordning.
- Ankommande meddelanden är eller kan "kategoriseras" på ett sådant sätt att kategorin blir en skalningsenhet för systemet.
Det här mönstret kanske inte är lämpligt för:
- Extremt höga dataflödesscenarier (miljontals meddelanden/minut eller sekund), eftersom FIFO-kravet begränsar den skalning som kan göras av systemet.
Design av arbetsbelastning
En arkitekt bör utvärdera hur mönstret Sekventiell konvoj kan användas i arbetsbelastningens design för att uppfylla de mål och principer som beskrivs i grundpelarna i Azure Well-Architected Framework. Till exempel:
| Grundpelare | Så här stöder det här mönstret pelarmål |
|---|---|
| Beslut om tillförlitlighetsdesign hjälper din arbetsbelastning att bli motståndskraftig mot fel och se till att den återställs till ett fullt fungerande tillstånd när ett fel inträffar. | Det här mönstret kan eliminera konkurrensförhållanden som är svåra att felsöka, omtvistad meddelandehantering eller andra lösningar för att hantera felaktigt ordnade meddelanden som kan leda till fel. - RE:02 Kritiska flöden - RE:07 Bakgrundsjobb |
Som med alla designbeslut bör du överväga eventuella kompromisser mot målen för de andra pelarna som kan införas med det här mönstret.
Exempel
I Azure kan det här mönstret implementeras med hjälp av Azure Service Bus-meddelandesessioner. För konsumenterna kan du använda antingen Logic Apps med Service Bus peek-lock-anslutningsappen eller Azure Functions med Service Bus-utlösaren.
I föregående exempel för orderspårning bearbetar du varje transaktionsregistermeddelande i den ordning det tas emot och skickar varje transaktion till en annan kö där kategorin är inställd på order-ID: t. En transaktion sträcker sig aldrig över flera beställningar i det här scenariot, så konsumenterna bearbetar varje kategori parallellt men FIFO inom kategorin.
Satsen processor fläkten outs meddelanden genom att de-batching innehållet i varje meddelande i den första kön:
Transaktionsregisterprocessorn tar hand om:
- Gå genom transaktionsregistret en transaktion i taget.
- Ange sessions-ID för meddelandet så att det matchar order-ID:t.
- Skickar varje transaktion i transaktionsregistret till en sekundär kö med sessions-ID inställt på order-ID: t.
Konsumenterna lyssnar på den sekundära kön där de bearbetar alla meddelanden med matchande order-ID i ordning från kön. Konsumenter använder peek-lock-läge .
När du överväger skalbarhet är transaktionsregisterkön en primär flaskhals. Olika transaktioner som bokförs i transaktionsregistret kan referera till samma order-ID. Meddelanden kan dock skickas efter transaktionsregistret till antalet beställningar i en serverlös miljö.
Nästa steg
Följande information kan vara relevant när du implementerar det här mönstret: