Mönster för prioritetskö

Azure Service Bus

Med mönstret för prioritetskö kan en arbetsbelastning bearbeta uppgifter med hög prioritet snabbare än aktiviteter med lägre prioritet. Det här mönstret använder meddelanden som skickas till en eller flera köer och är användbart i program som erbjuder olika servicenivågarantier till enskilda klienter.

Kontext och problem

Arbetsbelastningar behöver ofta hantera och bearbeta uppgifter med varierande prioritet och angelägenhetsgrad. Vissa uppgifter kräver omedelbar uppmärksamhet medan andra kan vänta. Om det inte går att åtgärda uppgifter med hög prioritet kan det påverka användarupplevelsen och bryta mot serviceavtal (SLA).

För att kunna hantera uppgifter effektivt baserat på deras prioritet behöver arbetsbelastningar en mekanism för att prioritera och utföra uppgifter i enlighet med detta. Vanligtvis bearbetar arbetsbelastningar uppgifter i den ordning de anländer, med hjälp av en fifo-köstruktur (first-in, first-out). Den här metoden tar inte hänsyn till aktiviteternas varierande betydelse.

Lösning

Med prioritetsköer kan arbetsbelastningar bearbeta uppgifter baserat på deras prioritet i stället för deras ankomstbeställning. Programmet som skickar ett meddelande till kön tilldelar meddelandet en prioritet och konsumenterna bearbetar meddelandena efter prioritet. Använd prioritetskömönstret när du har följande krav:

  • Hantera uppgifter med varierande angelägenhetsgrad och betydelse. Du har uppgifter med olika brådskande och viktiga nivåer och måste se till att du bearbetar mer kritiska uppgifter före mindre kritiska uppgifter.

  • Hantera olika serviceavtal. Du erbjuder olika servicenivågarantier till klienter som kräver och måste se till att klienter med hög prioritet får bättre prestanda och tillgänglighet.

  • Hantera olika arbetsbelastningshanteringsbehov. Du har en arbetsbelastning som måste åtgärda vissa uppgifter omedelbart och mindre brådskande uppgifter kan vänta.

Det finns två huvudsakliga metoder för att implementera mönstret Prioritetskö:

  • Enskild kö: Alla meddelanden skickas till en kö och varje meddelande tilldelas en prioritet.

  • Flera köer: Separata köer används för varje meddelandeprioritet.

Enskild kö

Med en enda kö tilldelar programmet (producenten) en prioritet till varje meddelande och skickar meddelandet till kön. Kön beställer meddelanden efter prioritet, vilket säkerställer att konsumenterna bearbetar meddelanden med högre prioritet före lägre prioritet.

Diagram som illustrerar en kömekanism som stöder meddelandeprioritering.
Figur 1. Arkitektur för en enskild kö och en enskild konsumentpool

Flera köer

Med flera köer kan du avgränsa meddelandet efter prioritet. Programmet tilldelar en prioritet till varje meddelande och dirigerar meddelandet till kön som motsvarar dess prioritet. Konsumenterna bearbetar meddelandena. En lösning med flera köer använder antingen en enskild konsumentpool eller flera konsumentpooler.

Flera konsumentpooler

Med flera konsumentpooler har varje kö konsumentresurser dedikerade till sig. Köer med högre prioritet bör använda fler konsumenter eller högre prestandanivåer för att bearbeta meddelanden snabbare än köer med lägre prioritet.

Använd flera konsumentpooler när du har:

  • Strikta prestandakrav: Flera konsumentpooler är nödvändiga när olika uppgiftsprioriteringar har strikta prestandakrav som måste uppfyllas oberoende av varandra.
  • Krav på hög tillförlitlighet: Flera konsumentpooler krävs för program där tillförlitlighet och felisolering är viktiga. Problem i en kö får inte påverka andra köer.
  • Komplexa program: Fördelaktigt för komplexa program med uppgifter som kräver olika bearbetningsegenskaper och prestandagarantier för olika uppgifter.

Diagram som illustrerar användningen av separata meddelandeköer för varje prioritet.
Figur 2. Arkitektur för flera köer och flera konsumentpooler.

Enskild konsumentpool

Med en enda konsumentpool delar alla köer en enda pool med konsumenter. Konsumenter bearbetar meddelanden från kön med högst prioritet först och bearbetar endast meddelanden från köer med lägre prioritet när det inte finns några meddelanden med hög prioritet. Därför bearbetar den enskilda konsumentpoolen alltid meddelanden med högre prioritet före lägre prioritet. Den här konfigurationen kan leda till att meddelanden med lägre prioritet ständigt fördröjs och eventuellt aldrig bearbetas.

Använd en enskild konsumentpool för:

  • Enkel hantering: En enskild konsumentpool är lämplig för program där enkel installation och underhåll är en prioritet. Det minskar komplexiteten i konfiguration och övervakning.
  • Enhetliga bearbetningsbehov: En enskild konsumentpool är användbar när den exakta typen av inkommande uppgifter är liknande.

Diagram som illustrerar användningen av separata meddelandeköer för varje prioritet.
Figur 3. Arkitektur för flera köer och en enskild konsumentpool.

Rekommendationer för prioritetskömönstret

Tänk på följande rekommendationer när du bestämmer dig för hur du implementerar prioritetskömönstret:

Allmänna rekommendationer

  • Definiera prioriteringar tydligt. Upprätta distinkta och tydliga prioritetsnivåer som är relevanta för din lösning. Ett meddelande med hög prioritet kan till exempel kräva bearbetning inom 10 sekunder. Identifiera kraven för hantering av högprioriterade objekt och allokera nödvändiga resurser i enlighet med detta.

  • Justera konsumentpooler dynamiskt. Skala storleken på konsumentpooler baserat på kölängden de betjänar.

  • Prioritera tjänstnivåer. Implementera prioritetsköer för att uppfylla affärsbehov som kräver prioriterad tillgänglighet eller prestanda. Olika kundgrupper kan till exempel få olika servicenivåer så att kunder med hög prioritet får bättre prestanda och tillgänglighet.

  • Kontrollera bearbetning med låg prioritet. I köer som stöder meddelandeprioritering ökar du dynamiskt prioriteten för föråldrade meddelanden om systemet tillåter att meddelanden med låg prioritet så småningom bearbetas.

  • Överväg kökostnader. Var medveten om de ekonomiska kostnader och bearbetningskostnader som är associerade med att kontrollera köer. Vissa kötjänster debiterar avgifter för att publicera, hämta och fråga meddelanden, vilket kan öka med antalet köer.

Rekommendationer för flera köer

  • Övervaka bearbetningshastigheter. För att säkerställa att meddelanden bearbetas enligt förväntade priser övervakar du kontinuerligt bearbetningshastigheten för köer med hög och låg prioritet.

  • Minimera kostnaderna. Bearbeta kritiska uppgifter omedelbart med tillgängliga konsumenter. Schemalägg mindre kritiska bakgrundsaktiviteter under mindre upptagna tider.

Rekommendationer för en enskild konsumentpool

  • Implementera preemption och suspension. Bestäm om alla objekt med hög prioritet måste bearbetas före objekt med lägre prioritet. Använd en algoritm som säkerställer att högprioriterade köer alltid betjänas före köer med lägre prioritet när du använder en enda pool med konsumenter för flera köer.

  • Optimera kostnader. Optimera driftskostnaderna genom att skala ned antalet konsumenter när du använder metoden med en kö. Meddelanden med hög prioritet bearbetas först, men kanske långsammare, medan meddelanden med lägre prioritet kan drabbas av längre fördröjningar.

Design av arbetsbelastning

En arkitekt bör utvärdera hur prioritetskömönstret kan uppfylla de mål och principer som beskrivs i grundpelarna i Azure Well-Architected Framework. Till exempel:

Grundpelare Så här stöder det här mönstret pelarmål
Beslut om tillförlitlighetsdesign hjälper din arbetsbelastning att bli motståndskraftig mot fel och se till att den återställs till ett fullt fungerande tillstånd när ett fel inträffar. Genom att separera objekt baserat på affärsprioritet kan du fokusera tillförlitlighetsarbetet på det mest kritiska arbetet.

- RE:02 Kritiska flöden
- RE:07 Bakgrundsjobb
Prestandaeffektivitet hjälper din arbetsbelastning att effektivt uppfylla kraven genom optimeringar inom skalning, data och kod. Genom att separera objekt baserat på affärsprioritet kan du fokusera prestandaarbetet på det mest tidskänsliga arbetet.

- PE:09 Kritiska flöden

Som med alla designbeslut bör du överväga eventuella kompromisser mot målen för de andra pelarna som kan införas med det här mönstret.

Exempel på mönstret Prioritetskö

I följande exempel i GitHub visas en implementering av mönstret Prioritetsköer med Hjälp av Azure Service Bus.

Diagram som visar hur du implementerar en prioritetskö med hjälp av Service Bus.
Figur 4. Arkitektur för PriorityQueue-exemplet i GitHub

Här är en översikt över arkitekturen:

  • Program (producent): Exemplet har ett program (PriorityQueueSender) som skapar meddelanden och tilldelar en anpassad egenskap som heter Priority i varje meddelande. Priority har värdet High eller Low.

  • Meddelandeköer och köer: I exemplet används Azure Service Bus som meddelandekö. Den använder två Azure Service Bus-köer, en för varje meddelandeprioritet (High och Low). Programmet (producenten) skickar meddelanden till rätt kö baserat på meddelandet Priority.

  • Flera konsumentpooler: I exemplet används flera konsumentpooler (PriorityQueueConsumerHigh och PriorityQueueConsumerLow) dedikerade för att läsa meddelanden från var och en av köerna.

Roll i exempelarkitektur Azure-tjänsten i exempel Namn i exempel
Program Azure Functions App PriorityQueueSender
Meddelandekökö Azure Service Bus <ditt Service Bus-namnområde>
Meddelandeköer Azure Service Bus-köer <dina könamn>
Konsumenter Azure Functions App PriorityQueueConsumerHigh
PriorityQueueConsumerLow

Följande mönster kan vara till hjälp när du implementerar det här mönstret:

  • Mönster för konkurrerande konsumenter: Det här mönstret omfattar implementering av flera konsumenter som lyssnar på samma kö och bearbetar uppgifter parallellt för att öka dataflödet. Endast en konsument bearbetar varje meddelande. Artikeln innehåller detaljerad information om fördelarna och nackdelarna med den här metoden.

  • Begränsningsmönster: Det här mönstret kan implementeras med hjälp av köer för att hantera begärandefrekvenser. Genom att använda prioriterade meddelanden kan begäranden från kritiska program eller kunder med högt värde prioriteras framför mindre viktiga.