Model prioritní fronty

Určete prioritu požadavků odesílaných do služeb, aby úloha zvlaizovala požadavky s vysokou prioritou rychleji než požadavky s nižší prioritou. Tento přístup používá zprávy odeslané do jedné nebo více front a je užitečný pro aplikace, které poskytují různé úrovně služeb nebo smlouvy o úrovni služeb (SLA) různým typům žádostí nebo zákazníkům.

Kontext a problém

Úlohy můžou potřebovat 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 SLA.

Aby úlohy fungovaly efektivně na základě jejich priority, potřebují úlohy mechanismus pro zpracování a spouštění úkolů odpovídajícím způsobem. Ve výchozím nastavení většina pracovních zátěží zpracovává úlohy v pořadí, v jakém přicházejí, pomocí 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, nikoli výhradně podle pořadí doručení. Aplikace nebo producent , který odešle požadavek, přiřadí zprávě hodnotu priority a příjemci zpracovávají zprávy podle priority. Vzor prioritní fronty řeší následující požadavky:

• Zpracovává ú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ává různé smlouvy SLA: Různým zákazníkům nabízíte různé smlouvy SLA a potřebujete zajistit, aby zákazníci s vysokou prioritou získali lepší výkon a dostupnost.

• Vyhovuje různým potřebám správy úloh: Máte úlohu, která potřebuje okamžitě řešit určité úkoly, zatímco méně naléhavé úkoly můžou čekat.

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

• Jedna fronta: Každé zprávě je přiřazena hodnota priority a všechny zprávy používají stejnou frontu.

• Více front: Každé zprávě je přiřazena hodnota priority a zprávy s jinou prioritou používají samostatné fronty.

Jedna fronta

V případě přístupu s jednou frontou aplikace přiřadí každé zprávě prioritu a odešle všechny zprávy do jedné 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.

Více front

Více front odděluje zprávy podle priority. Aplikace přiřadí každé zprávě prioritu a směruje zprávu do fronty, která odpovídá její prioritě, kde příjemci zpracovávají zprávy. Řešení s více frontami může používat buď jednu skupinu konzumentů, nebo více skupin konzumentů.

Fond s jedním uživatelem

V nastavení jednoho fondu sdílejí všechny fronty stejný fond příjemců. Příjemci zpracovávají zprávy z fronty s nejvyšší prioritou jako první a zpracovávají zprávy z front s nižší prioritou pouze v případě, že neexistují žádné zprávy s vysokou prioritou. V důsledku toho fondy s jediným příjemcem vždy zpracovávají 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ě nebudou nikdy zpracovány.

Použití jednoho fondu příjemců z následujících důvodů:

• Jednoduchá správa. Pokud je prioritou snadná instalace a údržba, použijte jeden fond příjemců. Jeden fond snižuje složitost konfigurace a monitorování.

• Požadavky na sjednocené zpracování Pokud jsou příchozí úkoly podobné typu, použijte jeden fond příjemců.

Více klientských skupin

V několika fondech příjemců má každá fronta vyhrazený fond příjemců. Fronty s vyšší prioritou používají 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ů z těchto důvodů:

• Striktní požadavky na výkon. Pokud mají různé priority úkolů přísné požadavky na výkon, které musí být splněny nezávisle, použijte více fondů příjemců.

• Požadavky na vysokou spolehlivost. Používejte pro aplikace více fondů příjemců, když jsou spolehlivost a izolace poruch zásadní a problémy v jedné frontě nesmí ovlivnit ostatní fronty.

• Složité aplikace. Použití více fondů příjemců pro složité aplikace, kde různé úlohy vyžadují různé charakteristiky zpracování a záruky výkonu.

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

Obecná doporučení

• Jasně definujte priority. Vytvořte jedinečné a jasné úrovně priority, které jsou pro vaše řešení relevantní. Můžete například definovat zprávy s vysokou prioritou jako zprávy, které vyžadují zpracování do 10 sekund. Identifikujte požadavky spotřebitele 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. Škálujte velikost fondů příjemců na základě délky fronty, kterou obsluhují.

• Monitorování stavu fronty Sledujte hloubku fronty, latenci zpracování, počet doručení a propustnost, abyste mohli detekovat backlogy a zpomalení, než ovlivní práci.

• Používejte fronty nedoručených zpráv. Přesuňte problematické zprávy do fronty nedoručených zpráv po konfigurovatelném počtu pokusů o doručení, aby jedna chybná zpráva nezablokovala prioritní tok zpracování.

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

• Zvažte zpracování s nízkou prioritou. Rozhodněte se, jestli se všechny položky s vysokou prioritou musí zpracovat před všemi položkami s nižší prioritou. Pokud je to možné, dynamicky zvyšte prioritu starých zpráv, abyste zajistili, že se zprávy s nízkou prioritou nakonec zpracují.

• Optimalizujte a 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ů.

  Pokud používáte jednu frontu, optimalizujte náklady snížením počtu konzumentů. 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.

• Chraňte procesory před špičkami poptávky. Pokud míra doručení producenta může překročit kapacitu zpracování příjemce, zkombinujte tento model se vzorem vyrovnávání zatíženíQueue-Based. Tento přístup zachytí nárůsty provozu a pomáhá zabránit přetížení prostředků zpracování podřízených dat.

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.

• Implementujte přednostní právo a pozastavení. Pokud používáte více front s jedním fondem příjemců, implementujte algoritmus, který zajišťuje, aby fronty s vysokou prioritou byly vždy obsluhovány před frontami s nižší prioritou.

• Zvažte náklady na frontu. Mějte na paměti finanční náklady spojené s kontrolou a zpracováním front. Některé služby front zpráv účtují poplatky za odesílání, načítání a dotazování zpráv. Tyto poplatky se mohou zvyšovat s rostoucím počtem front.

Kdy použít tento vzor

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

• Pro různé třídy práce, jako jsou požadavky zákazníků úrovně Premium a Standard, musíte splnit různé cíle latence nebo úrovně služeb.

• Práce přichází ve vlnách a kritické operace musíte chránit tak, že nejprve zpracujete zprávy s vysokou prioritou, zatímco úlohy s nižší prioritou odložíte na později.

Tento vzor nemusí být vhodný v těchto případech:

• Všechny pracovní položky mají podobnou obchodní důležitost a přísné zpracování FIFO je důležitější než plánování založené na prioritách.

• Úkoly mají silné závislosti řazení napříč úrovněmi priority a změna pořadí práce podle priority může způsobit nekonzistentní výsledky nebo vyžadovat složitou koordinaci logiky.

Návrh úloh

Vyhodnoťte, jak použít vzor prioritní fronty v návrhu úlohy k naplnění cílů a zásad popsaných v pilířích Azure Well-Architected Framework. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

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 podle obchodní priority vám umožní soustředit úsilí na nejkritičtější práci z hlediska spolehlivosti. - RE:02 Kritické toky
efektivita výkonu pomáhá vašim úlohám 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

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Příklad

Ukázka vzoru Prioritní fronta na GitHubu předvádí implementaci vzoru Prioritní fronta, který používá témata a odběry služby Azure Service Bus. Tento příklad nasazuje zabezpečený účet úložiště, prostředek Application Insights pro monitorování a obor názvů Service Bus, který umožňuje komunikaci mezi funkcemi odesílatele a příjemce.

Nasazení zahrnuje tři aplikace funkcí: jeden odesílatel a dva příjemci. Aplikace příjemců používají k simulaci stanovení priorit zpráv různé maximální počty instancí. Funkce funcPriorityQueueConsumerHigh může škálovat na 200 instancí, zatímco funcPriorityQueueConsumerLow funkce je omezená na 40 instancí. Všechny aplikace funkcí používají plán Flex Consumption a jsou připojené k Application Insights pro diagnostiku a monitorování.

Přiřazení rolí udělují zabezpečený přístup k Service Bus a úložišti pomocí spravovaných identit. Všechny aplikace funkcí používají stejný účet úložiště a prostředek Application Insights. Tato konfigurace centralizuje pozorovatelnost a protokolování.

Následující diagram znázorňuje architekturu prioritní fronty:

V předchozím diagramu:

1. Aplikace (producent). Aplikace PriorityQueueSender vytvoří zprávy, přiřadí vlastní vlastnost aplikace volanou Priority ke každé zprávě a nastaví Priority hodnotu na High nebo Low.

2. Zprostředkovatel zpráv a téma Zprostředkovatel zpráv Service Bus odesílá zprávy do jediného tématu Service Bus s názvem messages. Service Bus používá filtry SQL ke směrování každé zprávy do odběru s vysokou prioritou nebo s nízkou prioritou na základě jeho Priority hodnoty.

3. Více skupin spotřebitelů Skupiny příjemců PriorityQueueConsumerHigh a PriorityQueueConsumerLow reagují na zprávy z předplatných s vysokou nebo nízkou prioritou pomocí aktivačních událostí Service Bus ve službě Azure Functions.

Role v příkladu	Azure služba v příkladu	Název v příkladu
Aplikace (producent)	aplikace Azure Functions	PriorityQueueSender
Zprostředkovatel zpráv	Azure Service Bus	<váš obor názvů služby Service Bus>
Téma zprávy	téma služby Azure Service Bus	messages
Odběry zpráv	odběry služby Azure Service Bus	highPriority lowPriority
Spotřebitelé	aplikace Azure Functions	SpotřebitelPrioritníFrontyVysoké PriorityQueueConsumerLow

Další kroky

• Fronty, témata a předplatná ve službě Service Bus: Seznamte se s entitami služby Service Bus a s rozdíly mezi frontami a tématy.
• Detekce duplicit: Zjistěte, jak může Service Bus odmítat duplicitní zprávy, pokud odesílatel po nejistém odeslání zprávu odešle znovu.
• Fronty nedoručených zpráv: Zjistěte, jak Service Bus přesune zprávy, které nelze zpracovat do fronty nedoručených zpráv za účelem šetření nebo opětovného zpracování.
• Co je Azure Queue Storage?: Projděte si základní koncepty Azure Queue Storage a porovnejte ho s frontami Service Bus.

Související zdroje informací

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

• Vzor vyrovnávání zátěže pomocí fronty: Použijte frontu jako vyrovnávací paměť mezi příjmem požadavků a jejich zpracováním. Použijte jej se vzorem prioritní fronty, když potřebujete jak ochranu před nárazovými nárůsty, tak diferencované zpracování.

• Vzor konkurenčních příjemců: Implementujte několik příjemců, které naslouchají stejné frontě a paralelně zpracovávají úlohy, aby se zvýšila propustnost. Každá zpráva zpracovává pouze jeden příjemce.

• Vzor omezování: Implementujte omezování pomocí front k řízení míry požadavků. Prioritní zasílání zpráv můžete použít k určení priorit požadavků od kritických aplikací nebo zákazníků s vysokou hodnotou oproti méně důležitým.