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 jakém přicházejí, a zároveň je stále možné škálovat na více instancí, 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íci mohou škálovat nezávisle a často natahovat zprávy nezávisle na sobě pomocí modelu Konkurenční spotřebitelé.
Například systém sledování objednávek obdrží registr obsahující objednávky a příslušné operace na těchto objednávkách. Těmito operacemi může být vytvoření objednávky, přidání transakce do objednávky, úprava předchozí 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 objednávky. Počáteční fronta však obdrží hlavní knihy obsahující transakce pro mnoho objednávek, které mohou být prokládání.
Řešení
Nasdílení souvisejících zpráv do kategorií v rámci systému front a uzamčení naslouchacích procesů fronty a stažení pouze z jedné kategorie, jedné zprávy najednou.
Obecný vzor sekvenční konvoy vypadá takto:
Ve frontě můžou být zprávy pro různé kategorie prokládání, 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/měřítka Na jakou vlastnost příchozích zpráv můžete škálovat kapacitu? Ve scénáři sledování pořadí je tato vlastnost ID objednávky.
- Propustnost. Jaká je propustnost cílové zprávy? Pokud je to velmi vysoké, možná budete muset znovu zvážit požadavky FIFO. Můžete například vynutit počáteční/koncovou zprávu, seřadit podle času a pak odeslat dávku ke zpracování?
- Možnosti služby. Umožňuje volba sběrnice zpráv jednorázové zpracování zpráv v rámci fronty nebo kategorie fronty?
- Zvolná použitelnost. Jak do systému přidáte novou kategorii zpráv? Předpokládejme například, že výše popsaný systém registru je specifický pro jednoho zákazníka. Pokud jste potřebovali připojit nového zákazníka, mohli byste mít sadu procesorů registru, které distribuují práci podle ID zákazníka?
- Je možné, že příjemci můžou obdržet zprávu mimo pořadí kvůli proměnné latenci sítě při odesílání zpráv. Zvažte použití pořadových čísel k ověření řazení. Do poslední zprávy transakce můžete také zahrnout zvláštní příznak "konec sekvence". Technologie zpracování datových proudů, jako je Spark nebo Azure Stream Analytics, můžou zpracovávat zprávy v daném pořadí v časovém intervalu.
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říchozí zprávy jsou nebo mohou být "kategorizovány" takovým způsobem, že kategorie se stane jednotkou škálování systému.
Tento vzor nemusí být vhodný pro:
- Scénáře s extrémně vysokou propustností (miliony zpráv za minutu nebo sekundu), protože požadavek FIFO omezuje škálování, které může systém provádět.
Návrh úloh
Architekt by měl vyhodnotit způsob použití modelu Sekvenční konvoy v návrhu úloh k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:
| Pilíř | Jak tento model podporuje cíle pilíře |
|---|---|
| Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, aby se po selhání obnovila do plně funkčního stavu. | Tento model může eliminovat konflikty časování, které jsou obtížné vyřešit, zpracování sporných zpráv nebo jiná alternativní řešení pro adresování nesprávně seřazených zpráv, které můžou vést k poruchám. - RE:02 Kritické toky - RE:07 Úlohy na pozadí |
Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.
Příklad
V Azure je možné tento model implementovat pomocí relací zpráv služby Azure Service Bus. Pro uživatele můžete použít 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 registru v pořadí, v jakém byla přijata, a odešlete každou transakci do jiné fronty, kde je kategorie nastavena na ID objednávky. Transakce nebude v tomto scénáři nikdy zahrnovat více objednávek, takže příjemci zpracovávají každou kategorii paralelně, ale FIFO v kategorii.
Hlavní procesor rozdá zprávy zrušením dávkování obsahu každé zprávy v první frontě:
Procesor registru se postará o:
- Chůze hlavní knihy po jedné transakci najednou.
- Nastavení ID relace zprávy tak, aby odpovídalo ID objednávky.
- Odesílání každé transakce registru do sekundární fronty s ID relace nastavené na ID objednávky.
Příjemci 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 náhledu zámku .
Při zvažování škálovatelnosti je hlavní fronta primárním kritickým bodem. Různé transakce publikované do registru mohou odkazovat na stejné ID objednávky. Zprávy se ale můžou po registru rozdmístit podle počtu objednávek v bezserverovém prostředí.
Další kroky
Při implementaci tohoto modelu můžou být důležité tyto informace: