Vzor sekvenčního konvoye

Zpracovává sadu souvisejících zpráv v definovaném pořadí, aniž by docházelo k blokování zpracování dalších skupin zpráv.

Kontext a problém

Aplikace často potřebují zpracovat sekvenci zpráv v pořadí, v pořadí, ve které přicházejí, a současně musí být schopny škálovat na více velikosti, aby zvládly zvýšené zatížení. V distribuované architektuře není zpracování těchto zpráv v pořadí jednoduché, protože pracovní proces se může škálovat nezávisle a často si zprávy vyžádat nezávisle pomocí modelu konkurenčních spotřebitelů.

Například systém sledování objednávek obdrží hlavní knihy obsahující objednávky a příslušné operace s těmito objednávkami. Těmito operacemi může být vytvoření objednávky, přidání transakce do objednávky, úprava minulé transakce nebo odstranění objednávky. V tomto systému musí být operace prováděny způsobem FIFO (first-in-first-out), ale pouze na úrovni pořadí. Počáteční fronta ale obdrží hlavní knihy obsahující transakce pro mnoho objednávek, které mohou být prokládané.

Řešení

Naslouchací objekty fronty zamknou a vyžádají pouze jednu kategorii , jednu zprávu po jedné.

Obecný vzor sekvenční konvoy vypadá takhle:

Ve frontě mohou být zprávy pro různé kategorie prokládané, jak je znázorněno v následujícím diagramu:

Problémy a důležité informace

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

• Jednotka kategorie/škálování. U jaké vlastnosti příchozích zpráv můžete škálovat na více? Ve scénáři sledování objednávek je tato vlastnost ID objednávky.
• Propustnost. Jaká je vaše cílová propustnost zpráv? Pokud je velmi vysoká, možná budete muset znovu zvážit své požadavky FIFO. Můžete například vynutit počáteční/koncovou zprávu, řadit podle času a pak odeslat dávku ke zpracování?
• Možnosti služeb. Umožňuje váš výběr sběrnice zpráv zpracování zpráv v rámci fronty nebo kategorie fronty po jednom?
• Vyvolatelnost. Jak do systému přidáte novou kategorii zpráv? Předpokládejme například, že výše popsaný systém hlavní knihy je specifický pro jednoho zákazníka. Pokud byste potřebovali onboardovat nového zákazníka, mohli byste mít sadu procesorů v hlavní knize, které distribuují práci podle ID zákazníka?
• Je možné, že můžou spotřebiteli obdržet zprávu mimo pořadí kvůli proměnlivé latenci sítě při odesílání zpráv. Zvažte použití sekvenčních čísel k ověření řazení. Do poslední zprávy transakce můžete také zahrnout speciální příznak "konec sekvence". Technologie zpracování datových proudů, jako je Spark nebo Azure Stream Analytics mohou zpracovávat zprávy v pořadí v rámci časového okna.

Kdy se má tento model použít

Tento model použijte v těchto případech:

• Máte zprávy, které přicházejí v pořadí a musí být zpracovány ve stejném pořadí.
• Přicházející zprávy jsou nebo mohou být "zařazeny do kategorií" takovým způsobem, že se kategorie stane jednotkou škálování pro systém.

Tento model nemusí být vhodný pro:

• Extrémně scénáře s vysokou propustností (miliony zpráv za minutu nebo sekundu), protože požadavek FIFO omezuje škálování, které může systém provést.

Příklad

V Azure je možné tento model implementovat pomocí relací Service Bus zpráv Azure. Pro uživatele můžete použít buď konektor Logic Apps s konektorem Service Bus peek-lock, nebo Azure Functions s triggerem Service Bus.

V předchozím příkladu sledování objednávek zpracujte každou zprávu z hlavní knihy v pořadí, v němž byla přijata, a každou transakci odešlete do jiné fronty, kde je kategorie nastavená na ID objednávky. Transakce v tomto scénáři nikdy nebude zahrnovat více objednávek, takže spotřebitelé zpracovávají každou kategorii paralelně, ale FIFO v rámci kategorie.

Procesor ledge rozdmýchá zprávy tak, že se obsah každé zprávy v první frontě vysune z dávky:

Procesor hlavní knihy se postará o:

1. Procházení po jedné transakci v hlavní knize.
2. Nastavení ID relace zprávy tak, aby odpovídalo ID objednávky.
3. Odeslání každé transakce hlavní knihy do sekundární fronty s ID relace nastaveným na ID objednávky.

Spotřebiteli naslouchají sekundární frontě, kde zpracovávají všechny zprávy s odpovídajícími ID objednávek v pořadí z fronty. Uživatelé používají režim peek-lock.

Při zvažování škálovatelnosti je primárním kritickým bodem fronta hlavní knihy. Různé transakce účtované do hlavní knihy mohou odkazovat na stejné ID objednávky. Zprávy se ale po hlavní knize dějí podle počtu objednávek v bez serveru.

Další kroky

Při implementaci tohoto modelu můžou být důležité tyto informace:

• Relace zpráv: fifo (first in, first out)
• Zpráva Peek-Lock (nedestruktivní čtení)
• Doručování korelovaných zpráv v Logic Apps pomocí Service Bus relací (blog MSDN)