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 úloh zpracovává úlohy v pořadí, v jakém přicházejí, pomocí struktury fronty FIFO (first-in). 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. Model 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 jednom přístupu fronty přiřadí aplikace 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 frontou může používat jeden fond příjemců nebo více fondů příjemců.

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 jednotlivých příjemců vždy zpracovávají zprávy s vyšší prioritou před zprávami s nižší prioritou. Toto nastavení může vést k neustálému zpoždění zpráv s nižší prioritou a potenciálně nikdy ke zpracování.

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žití více fondů příjemců z následujících 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žití více fondů příjemců pro aplikace v případě, že spolehlivost a izolace chyb jsou kritické a problémy v jedné frontě nesmí mít vliv na jiné 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. Po konfigurovatelném počtu pokusů o doručení přesuňte jedované zprávy do fronty nedoručených zpráv, aby jedna chybná zpráva nezablokovala prioritní cestu.

• 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 škálováním zpět na počet příjemců. 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 fronty účtují poplatky za účtování, načítání a dotazování zpráv. Tyto poplatky se můžou zvýšit o počet 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í v nárůstech a je nutné chránit kritické operace zpracováním zpráv s vysokou prioritou nejprve při odložení práce s nižší prioritou.

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 model Prioritní fronta v návrhu úlohy k řešení cílů a principů 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

Příklad vzoru Prioritní fronta na GitHub ukazuje implementaci modelu Prioritní fronta, který používá Azure Service Bus témata a odběry. V příkladu se nasadí zabezpečený účet úložiště, prostředek Application Insights pro monitorování a obor názvů Service Bus, který umožňuje komunikaci mezi odesílateli a funkcemi příjemce.

Nasazení zahrnuje tři aplikace funkcí: jeden odesílatel a dva uživatele. 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í sdílejí 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 Service Bus zprostředkovatele zpráv odesílá zprávy do jednoho Service Bus tématu 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 fondů příjemců Fondy PriorityQueueConsumerHigh příjemců PriorityQueueConsumerLow reagují na zprávy z odběrů s vysokou prioritou nebo s nízkou prioritou pomocí triggerů Azure Functions Service Bus.

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	Azure Service Bus předplatných	highPriority lowPriority
Spotřebitelé	aplikace Azure Functions	SpotřebitelPrioritníFrontyVysoké PriorityQueueConsumerLow

Další kroky

• Service Bus fronty, témata a odběry: Projděte si entity Service Bus a rozdíly mezi frontami a tématy.
• Detekce duplicit: Zjistěte, jak Service Bus může odmítnout duplicitní zprávy, když odesílatel po neurčité odeslání opakuje.
• 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:

• Queue-Based vzor vyrovnávání zatížení: Použijte frontu jako vyrovnávací paměť mezi příjmem a zpracováním požadavků. Používejte ho se vzorem Prioritní fronta, když potřebujete ochranu proti nárazovým nárůstu i diferencované zpracování.

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

• Model omezování: Implementujte omezování pomocí front ke správě sazeb 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.