Model prioritní fronty

Azure Service Bus

Model prioritní fronty umožňuje úlohám zpracovávat úlohy s vysokou prioritou rychleji než úkoly s nižší prioritou. Tento model používá zprávy odeslané do jedné nebo více front a je užitečný v aplikacích, které nabízejí různé záruky na úrovni služeb jednotlivým klientům.

Kontext a problém

Úlohy často potřebují spravovat a zpracovávat úlohy s různými úrovněmi důležitosti a naléhavosti. Některé úkoly vyžadují okamžitou pozornost, zatímco ostatní můžou čekat. Selhání řešení úloh s vysokou prioritou může mít vliv na uživatelské prostředí a porušení smluv o úrovni služeb (SLA).

Aby úlohy efektivně zpracovávaly na základě jejich priority, potřebují úlohy mechanismus pro stanovení priority a provádění úkolů odpovídajícím způsobem. Úlohy jsou obvykle zpracovávány v pořadí, v jakém přicházejí, pomocí struktury fronty FIFO (first-in, first-out). Tento přístup nebere v úvahu různou důležitost úkolů.

Řešení

Prioritní fronty umožňují úlohám zpracovávat úlohy na základě jejich priority místo pořadí doručení. Aplikace, která odesílá zprávu do fronty, přiřadí zprávě prioritu a příjemci zprávy zpracovávají podle priority. Vzor prioritní fronty použijte, pokud máte následující požadavky:

• Zpracujte úkoly s různou naléhavostí a důležitostí. Máte úkoly s různými úrovněmi naléhavosti a důležitosti a potřebujete zajistit, abyste zpracovávali důležitější úkoly před méně kritickými úkoly.

• Zpracování různých smluv o úrovni služeb Klientům nabízíte různé záruky na úrovni služeb a potřebujete zajistit, aby klienti s vysokou prioritou dostávali lepší výkon a dostupnost.

• Uspokojit různé potřeby správy pracovních úloh Máte pracovní zátěž, která potřebuje okamžitě řešit určité úkoly, zatímco méně naléhavé úkoly mohou počkat.

Existují dva hlavní přístupy k implementaci vzoru Prioritní fronta:

• Jedna fronta: Všechny zprávy se odesílají do jedné fronty a každá zpráva má přiřazenou prioritu.

• Více front: Pro každou prioritu zprávy se používají samostatné fronty.

Jedna fronta

Při použití jedné fronty aplikace (producent) každé zprávě přiřadí prioritu a odešle zprávu do fronty. Fronta objednává zprávy podle priority a zajišťuje, aby příjemci zpracovávali zprávy s vyšší prioritou před zprávami s nižší prioritou.

Obrázek č. 1. Architektura jedné fronty a fondu spotřebitelů

Více front

Více front umožňuje oddělit zprávy podle priority. Aplikace přiřadí každé zprávě prioritu a směruje zprávu do fronty odpovídající její prioritě. Příjemci zpracovávají zprávy. Řešení s více frontami používá buď jeden spotřebitelský fond, nebo více spotřebitelských fondů.

Více klientských skupin

U více skupin spotřebitelů má každá fronta přidělené zdroje spotřebitelů. Fronty s vyšší prioritou by měly používat více příjemců nebo vyšší úrovně výkonu ke zpracování zpráv rychleji než fronty s nižší prioritou.

Použijte více fondů příjemců, pokud máte:

• Přísné požadavky na výkon: Pokud různé priority úkolů vyžadují přísné požadavky na výkon, které musí být splněny nezávisle, jsou nezbytné více pooly spotřebitelů.
• Požadavky na vysokou spolehlivost: Pro aplikace, u kterých je důležitá spolehlivost a izolace chyb, je vyžadováno více fondů příjemců. Problémy v jedné frontě nesmí mít vliv na jiné fronty.
• Složité aplikace: Přínosné pro složité aplikace s úlohami, které vyžadují různé charakteristiky zpracování a záruky výkonu pro různé úlohy.

Obrázek č. 2. Architektura více front a více skupin spotřebitelů

Fond s jedním uživatelem

S jediným fondem příjemců sdílejí všechny fronty jeden fond příjemců. Příjemci zpracovávají zprávy z fronty s nejvyšší prioritou jako první a zpracovávají pouze zprávy z front s nižší prioritou, pokud neexistují žádné zprávy s vysokou prioritou. Výsledkem je, že spotřebitelský fond vždy zpracovává zprávy s vyšší prioritou před zprávami s nižší prioritou. Toto nastavení může vést k tomu, že zprávy s nižší prioritou budou neustále zpožďovány a potenciálně nikdy nemusí dojít ke zpracování.

Použijte jeden fond příjemců pro:

• Jednoduchá správa: Jeden fond příjemců je vhodný pro aplikaci, kde je prioritou snadné nastavení a údržby. Snižuje složitost konfigurace a monitorování.
• Potřeby sjednoceného zpracování: Jeden fond příjemců je užitečný, když je přesná povaha příchozích úkolů podobná.

Obrázek č. 3. Architektura více front a jedné uživatelské skupiny

Doporučení pro model prioritní fronty

Při rozhodování o implementaci vzoru prioritní fronty zvažte následující doporučení:

Obecná doporučení

• Jasně definujte priority. Vytvořte jedinečné a jasné úrovně priority, které jsou pro vaše řešení relevantní. Například zpráva s vysokou prioritou může vyžadovat zpracování do 10 sekund. Určete požadavky na zpracování položek s vysokou prioritou a odpovídajícím způsobem přidělte potřebné prostředky.

• Dynamicky upravte uživatelské fondy. Upravte velikost skupin spotřebitelů na základě délky fronty, kterou obsluhují.

• Určete prioritu úrovní služeb. Implementujte prioritní fronty pro splnění obchodních potřeb, které vyžadují prioritní dostupnost nebo výkon. Různé skupiny zákazníků můžou například přijímat různé úrovně služeb, aby zákazníci s vysokou prioritou mohli dosáhnout lepšího výkonu a dostupnosti.

• Zajistěte zpracování s nízkou prioritou. Ve frontách, které podporují stanovení priority zpráv, dynamicky zvyšte prioritu zastaralých zpráv, pokud systém umožňuje zajistit, aby se zprávy s nízkou prioritou nakonec zpracovávaly.

• Zvažte náklady na frontu. Mějte na paměti finanční a provozní náklady spojené s kontrolou front. Některé služby fronty účtují poplatky za odeslání, načítání a dotazy na zprávy, což může vzrůst s počtem front.

Doporučení pro více front

• Monitorujte rychlost zpracování. Aby se zajistilo, že se zprávy zpracovávají očekávaným tempem, nepřetržitě monitorujte rychlost zpracování front s vysokou a nízkou prioritou.

• Minimalizujte náklady. Zpracování kritických úloh okamžitě s dostupnými příjemci Naplánujte méně důležité úlohy na pozadí během méně zaneprázdněných časů.

Doporučení pro jednu skupinu spotřebitelů

• Implementujte přednostní právo a pozastavení. Rozhodněte se, jestli musí být všechny položky s vysokou prioritou zpracovány před všemi položkami s nižší prioritou. Použijte algoritmus, který zajišťuje, že fronty s vysokou prioritou se vždy obsluhují před frontami s nižší prioritou, když pro více front použijete jeden fond příjemců.

• Optimalizujte náklady. Optimalizujte provozní náklady snížením počtu konzumentů při použití jedno-frontového přístupu. Zprávy s vysokou prioritou se nejprve zpracovávají, ale možná pomaleji, zatímco zprávy s nižší prioritou můžou čelit delším zpožděním.

Návrh úloh

Architekt by měl vyhodnotit, jak model prioritní fronty dokáže řešit cíle a principy popsané v pilířích architektury Azure Well-Architected. 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.	Oddělení položek na základě obchodní priority vám umožní zaměřit úsilí na spolehlivost u nejdůležitějších úkolů. - RE:02 Kritické toky - RE:07 Úlohy na pozadí
Efektivita výkonu pomáhá vaší úloze efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Oddělení položek na základě obchodní priority umožňuje soustředit se na výkon na většinu práce citlivé na čas. - PE:09 Kritické toky

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 schématu prioritní fronty

Následující příklad v GitHub ukazuje implementaci vzoru Prioritních front pomocí Azure Service Bus.

Obrázek č. 4. Architektura příkladu PriorityQueue v GitHub

Tady je přehled architektury:

• Aplikace (producent): Příklad obsahuje aplikaci (PriorityQueueSender), která vytváří zprávy a přiřazuje vlastní vlastnost volanou Priority v každé zprávě. Priority má hodnotu High nebo Low.

• Zprostředkovatel zpráv a fronty: Jako zprostředkovatel zpráv je v příkladu použit Azure Service Bus. Používá dvě fronty Azure Service Bus, jednu pro každou prioritu zprávy (High a Low). Aplikace (producent) odesílá zprávy do správné fronty na základě obsahu/znění zprávy Priority.

• Více fondů spotřebitelů: Příklad používá více fondů spotřebitelů (PriorityQueueConsumerHigh a PriorityQueueConsumerLow) vyhrazených ke čtení zpráv z každé z front.

Role v ukázkové architektuře	Azure služba v příkladu	Název v příkladu
Aplikace	aplikace Azure Functions	PriorityQueueSender
Zprostředkovatel front zpráv	Azure Service Bus	< váš obor názvů služby Service Bus>
Fronty zpráv	Azure Service Bus fronty	< vaše názvy front>
Příjemci	aplikace Azure Functions	SpotřebitelPrioritníFrontyVysoké PriorityQueueConsumerLow

Související prostředky

Při implementaci tohoto modelu vám můžou být užitečné následující vzory:

• Model konkurenčních příjemců: Tento model zahrnuje implementaci více příjemců, kteří paralelně naslouchají stejným úlohám fronty a procesů za účelem zvýšení propustnosti. Každá zpráva zpracovává pouze jeden příjemce. Článek obsahuje podrobné informace o výhodách a nevýhodách tohoto přístupu.

• Vzorec omezování: Tento vzorec lze implementovat pomocí front ke správě rychlostí požadavků. Díky využití prioritního zasílání zpráv mohou být žádosti od kritických aplikací a zákazníků s vysokou hodnotou upřednostňovány před méně důležitými.

Model prioritní fronty umožňuje úlohám zpracovávat úlohy s vysokou prioritou rychleji než úkoly s nižší prioritou. Tento model používá zprávy odeslané do jedné nebo více front a je užitečný v aplikacích, které nabízejí různé záruky na úrovni služeb jednotlivým klientům.

Kontext a problém

Úlohy často potřebují spravovat a zpracovávat úlohy s různými úrovněmi důležitosti a naléhavosti. Některé úkoly vyžadují okamžitou pozornost, zatímco ostatní můžou čekat. Selhání řešení úloh s vysokou prioritou může mít vliv na uživatelské prostředí a porušení smluv o úrovni služeb (SLA).

Aby úlohy efektivně zpracovávaly na základě jejich priority, potřebují úlohy mechanismus pro stanovení priority a provádění úkolů odpovídajícím způsobem. Úlohy jsou obvykle zpracovávány v pořadí, v jakém přicházejí, pomocí struktury fronty FIFO (first-in, first-out). Tento přístup nebere v úvahu různou důležitost úkolů.

Řešení

Prioritní fronty umožňují úlohám zpracovávat úlohy na základě jejich priority místo pořadí doručení. Aplikace, která odesílá zprávu do fronty, přiřadí zprávě prioritu a příjemci zprávy zpracovávají podle priority. Vzor prioritní fronty použijte, pokud máte následující požadavky:

• Zpracujte úkoly s různou naléhavostí a důležitostí. Máte úkoly s různými úrovněmi naléhavosti a důležitosti a potřebujete zajistit, abyste zpracovávali důležitější úkoly před méně kritickými úkoly.

• Zpracování různých smluv o úrovni služeb Klientům nabízíte různé záruky na úrovni služeb a potřebujete zajistit, aby klienti s vysokou prioritou dostávali lepší výkon a dostupnost.

• Uspokojit různé potřeby správy pracovních úloh Máte pracovní zátěž, která potřebuje okamžitě řešit určité úkoly, zatímco méně naléhavé úkoly mohou počkat.

Existují dva hlavní přístupy k implementaci vzoru Prioritní fronta:

• Jedna fronta: Všechny zprávy se odesílají do jedné fronty a každá zpráva má přiřazenou prioritu.

• Více front: Pro každou prioritu zprávy se používají samostatné fronty.

Jedna fronta

Při použití jedné fronty aplikace (producent) každé zprávě přiřadí prioritu a odešle zprávu do fronty. Fronta objednává zprávy podle priority a zajišťuje, aby příjemci zpracovávali zprávy s vyšší prioritou před zprávami s nižší prioritou.

Obrázek č. 1. Architektura jedné fronty a fondu spotřebitelů

Více front

Více front umožňuje oddělit zprávy podle priority. Aplikace přiřadí každé zprávě prioritu a směruje zprávu do fronty odpovídající její prioritě. Příjemci zpracovávají zprávy. Řešení s více frontami používá buď jeden spotřebitelský fond, nebo více spotřebitelských fondů.

Více klientských skupin

U více skupin spotřebitelů má každá fronta přidělené zdroje spotřebitelů. Fronty s vyšší prioritou by měly používat více příjemců nebo vyšší úrovně výkonu ke zpracování zpráv rychleji než fronty s nižší prioritou.

Použijte více fondů příjemců, pokud máte:

• Přísné požadavky na výkon: Pokud různé priority úkolů vyžadují přísné požadavky na výkon, které musí být splněny nezávisle, jsou nezbytné více pooly spotřebitelů.
• Požadavky na vysokou spolehlivost: Pro aplikace, u kterých je důležitá spolehlivost a izolace chyb, je vyžadováno více fondů příjemců. Problémy v jedné frontě nesmí mít vliv na jiné fronty.
• Složité aplikace: Přínosné pro složité aplikace s úlohami, které vyžadují různé charakteristiky zpracování a záruky výkonu pro různé úlohy.

Obrázek č. 2. Architektura více front a více skupin spotřebitelů

Fond s jedním uživatelem

S jediným fondem příjemců sdílejí všechny fronty jeden fond příjemců. Příjemci zpracovávají zprávy z fronty s nejvyšší prioritou jako první a zpracovávají pouze zprávy z front s nižší prioritou, pokud neexistují žádné zprávy s vysokou prioritou. Výsledkem je, že spotřebitelský fond vždy zpracovává zprávy s vyšší prioritou před zprávami s nižší prioritou. Toto nastavení může vést k tomu, že zprávy s nižší prioritou budou neustále zpožďovány a potenciálně nikdy nemusí dojít ke zpracování.

Použijte jeden fond příjemců pro:

• Jednoduchá správa: Jeden fond příjemců je vhodný pro aplikaci, kde je prioritou snadné nastavení a údržby. Snižuje složitost konfigurace a monitorování.
• Potřeby sjednoceného zpracování: Jeden fond příjemců je užitečný, když je přesná povaha příchozích úkolů podobná.

Obrázek č. 3. Architektura více front a jedné uživatelské skupiny

Doporučení pro model prioritní fronty

Při rozhodování o implementaci vzoru prioritní fronty zvažte následující doporučení:

Obecná doporučení

• Jasně definujte priority. Vytvořte jedinečné a jasné úrovně priority, které jsou pro vaše řešení relevantní. Například zpráva s vysokou prioritou může vyžadovat zpracování do 10 sekund. Určete požadavky na zpracování položek s vysokou prioritou a odpovídajícím způsobem přidělte potřebné prostředky.

• Dynamicky upravte uživatelské fondy. Upravte velikost skupin spotřebitelů na základě délky fronty, kterou obsluhují.

• Určete prioritu úrovní služeb. Implementujte prioritní fronty pro splnění obchodních potřeb, které vyžadují prioritní dostupnost nebo výkon. Různé skupiny zákazníků můžou například přijímat různé úrovně služeb, aby zákazníci s vysokou prioritou mohli dosáhnout lepšího výkonu a dostupnosti.

• Zajistěte zpracování s nízkou prioritou. Ve frontách, které podporují stanovení priority zpráv, dynamicky zvyšte prioritu zastaralých zpráv, pokud systém umožňuje zajistit, aby se zprávy s nízkou prioritou nakonec zpracovávaly.

• Zvažte náklady na frontu. Mějte na paměti finanční a provozní náklady spojené s kontrolou front. Některé služby fronty účtují poplatky za odeslání, načítání a dotazy na zprávy, což může vzrůst s počtem front.

Doporučení pro více front

• Monitorujte rychlost zpracování. Aby se zajistilo, že se zprávy zpracovávají očekávaným tempem, nepřetržitě monitorujte rychlost zpracování front s vysokou a nízkou prioritou.

• Minimalizujte náklady. Zpracování kritických úloh okamžitě s dostupnými příjemci Naplánujte méně důležité úlohy na pozadí během méně zaneprázdněných časů.

Doporučení pro jednu skupinu spotřebitelů

• Implementujte přednostní právo a pozastavení. Rozhodněte se, jestli musí být všechny položky s vysokou prioritou zpracovány před všemi položkami s nižší prioritou. Použijte algoritmus, který zajišťuje, že fronty s vysokou prioritou se vždy obsluhují před frontami s nižší prioritou, když pro více front použijete jeden fond příjemců.

• Optimalizujte náklady. Optimalizujte provozní náklady snížením počtu konzumentů při použití jedno-frontového přístupu. Zprávy s vysokou prioritou se nejprve zpracovávají, ale možná pomaleji, zatímco zprávy s nižší prioritou můžou čelit delším zpožděním.

Návrh úloh

Architekt by měl vyhodnotit, jak model prioritní fronty dokáže řešit cíle a principy popsané v pilířích architektury Azure Well-Architected. 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.	Oddělení položek na základě obchodní priority vám umožní zaměřit úsilí na spolehlivost u nejdůležitějších úkolů. - RE:02 Kritické toky - RE:07 Úlohy na pozadí
Efektivita výkonu pomáhá vaší úloze efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Oddělení položek na základě obchodní priority umožňuje soustředit se na výkon na většinu práce citlivé na čas. - PE:09 Kritické toky

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 schématu prioritní fronty

Následující příklad v GitHub ukazuje implementaci vzoru Prioritních front pomocí Azure Service Bus.

Obrázek č. 4. Architektura příkladu PriorityQueue v GitHub

Tady je přehled architektury:

• Aplikace (producent): Příklad obsahuje aplikaci (PriorityQueueSender), která vytváří zprávy a přiřazuje vlastní vlastnost volanou Priority v každé zprávě. Priority má hodnotu High nebo Low.

• Zprostředkovatel zpráv a fronty: Jako zprostředkovatel zpráv je v příkladu použit Azure Service Bus. Používá dvě fronty Azure Service Bus, jednu pro každou prioritu zprávy (High a Low). Aplikace (producent) odesílá zprávy do správné fronty na základě obsahu/znění zprávy Priority.

• Více fondů spotřebitelů: Příklad používá více fondů spotřebitelů (PriorityQueueConsumerHigh a PriorityQueueConsumerLow) vyhrazených ke čtení zpráv z každé z front.

Role v ukázkové architektuře	Azure služba v příkladu	Název v příkladu
Aplikace	aplikace Azure Functions	PriorityQueueSender
Zprostředkovatel front zpráv	Azure Service Bus	< váš obor názvů služby Service Bus>
Fronty zpráv	Azure Service Bus fronty	< vaše názvy front>
Příjemci	aplikace Azure Functions	SpotřebitelPrioritníFrontyVysoké PriorityQueueConsumerLow

Související prostředky

Při implementaci tohoto modelu vám můžou být užitečné následující vzory:

• Model konkurenčních příjemců: Tento model zahrnuje implementaci více příjemců, kteří paralelně naslouchají stejným úlohám fronty a procesů za účelem zvýšení propustnosti. Každá zpráva zpracovává pouze jeden příjemce. Článek obsahuje podrobné informace o výhodách a nevýhodách tohoto přístupu.

• Vzorec omezování: Tento vzorec lze implementovat pomocí front ke správě rychlostí požadavků. Díky využití prioritního zasílání zpráv mohou být žádosti od kritických aplikací a zákazníků s vysokou hodnotou upřednostňovány před méně důležitými.