Patroon voor wachtrij met prioriteit

Prioriteit geven aan aanvragen die naar services worden verzonden, zodat aanvragen met een hoge prioriteit sneller worden verwerkt dan aanvragen met een lagere prioriteit. Deze benadering maakt gebruik van berichten die naar een of meer wachtrijen worden verzonden en is handig voor toepassingen die verschillende serviceniveaus of serviceovereenkomsten (SLA's) bieden aan verschillende aanvraagtypen of klanten.

Context en probleem

Workloads moeten mogelijk taken beheren en verwerken met verschillende niveaus van belang en urgentie. Voor sommige taken is direct aandacht vereist, terwijl anderen kunnen wachten. Het niet afhandelen van taken met hoge prioriteit kan de gebruikerservaring beïnvloeden en SLA’s schenden.

Als u taken efficiënt wilt afhandelen op basis van hun prioriteit, hebben workloads een mechanisme nodig om taken dienovereenkomstig te verwerken en uit te voeren. De meeste workloads verwerken taken standaard in de volgorde waarin ze binnenkomen, met behulp van een FIFO-wachtrijstructuur (first-in, first-out). Deze benadering houdt geen rekening met verschillende taakbelangen.

Oplossing

Prioriteitswachtrijen stellen workloads in staat taken te verwerken op basis van hun prioriteit in plaats van strikt in volgorde van binnenkomst. De toepassing of producent die een aanvraag verzendt, wijst een prioriteitswaarde toe aan het bericht en consumenten verwerken de berichten op prioriteit. Het patroon Wachtrij met prioriteit voldoet aan de volgende vereisten:

  • Verwerkt taken met verschillende niveaus van urgentie en belang: U hebt taken met verschillende niveaus van urgentie en belang en moet ervoor zorgen dat u belangrijkere taken verwerkt vóór minder belangrijke taken.

  • Verwerkt verschillende SLA's: U biedt verschillende SLA's aan verschillende klanten en moet ervoor zorgen dat klanten met een hoge prioriteit betere prestaties en beschikbaarheid krijgen.

  • Geschikt voor verschillende behoeften voor workloadbeheer: U hebt een workload die bepaalde taken onmiddellijk moet aanpakken, terwijl minder urgente taken kunnen wachten.

Er zijn twee hoofdmethoden voor het implementeren van het patroon Prioriteitswachtrij:

  • Eén wachtrij: Aan elk bericht wordt een prioriteitswaarde toegewezen en alle berichten gebruiken dezelfde wachtrij.

  • Meerdere wachtrijen: Aan elk bericht wordt een prioriteitswaarde toegewezen en berichten met een andere prioriteit maken gebruik van afzonderlijke wachtrijen.

Eén wachtrij

In één wachtrijbenadering wijst de toepassing een prioriteit toe aan elk bericht en verzendt alle berichten naar één wachtrij. De wachtrij bestelt berichten op prioriteit, zodat consumenten berichten met een hogere prioriteit verwerken vóór berichten met een lagere prioriteit.

Diagram met een wachtrijmechanisme dat ondersteuning biedt voor prioriteitstelling van berichten.

Meerdere wachtrijen

Meerdere wachtrijen scheiden berichten op prioriteit. De toepassing wijst een prioriteit toe aan elk bericht en stuurt het bericht door naar de wachtrij die overeenkomt met de prioriteit, waarbij consumenten de berichten verwerken. Een oplossing met meerdere wachtrijen kan één groep consumenten of meerdere consumentengroepen gebruiken.

Eén consumentengroep

In een configuratie met één pool delen alle wachtrijen dezelfde consumerpool. Consumenten verwerken berichten van de wachtrij met de hoogste prioriteit eerst en verwerken berichten van wachtrijen met lagere prioriteit alleen wanneer er geen berichten met hoge prioriteit meer zijn. Als gevolg hiervan verwerken individuele consumentengroepen berichten met een hogere prioriteit altijd vóór degenen met een lagere prioriteit. Deze instelling kan ertoe leiden dat berichten met een lagere prioriteit voortdurend worden vertraagd en mogelijk nooit worden verwerkt.

Diagram dat het gebruik van één consumentengroep voor alle prioriteiten illustreert.

Gebruik één consumentengroep om de volgende redenen:

  • Eenvoudig beheer. Gebruik één consumentengroep wanneer eenvoudig instellen en onderhouden een prioriteit is. Eén pool vermindert de configuratie en bewakingscomplexiteit.

  • Geïntegreerde verwerkingsbehoeften. Gebruik één consumentengroep wanneer de binnenkomende taken vergelijkbaar zijn in het type.

Meerdere consumentengroepen

In een meerdere consumentengroep heeft elke wachtrij een toegewezen consumentengroep. Wachtrijen met een hogere prioriteit gebruiken meer consumenten of hogere prestatielagen om berichten sneller te verwerken dan wachtrijen met lagere prioriteit.

Diagram dat het gebruik van afzonderlijke consumentengroepen voor elke prioriteit illustreert.

Gebruik om de volgende redenen meerdere consumentengroepen:

  • Strikte prestatievereisten. Gebruik meerdere consumentengroepen wanneer verschillende taakprioriteiten strikte prestatievereisten hebben waaraan onafhankelijk moet worden voldaan.

  • Hoge betrouwbaarheidsbehoeften. Gebruik meerdere consumentengroepen voor toepassingen wanneer betrouwbaarheid en foutisolatie essentieel zijn en problemen in de ene wachtrij mogen geen invloed hebben op andere wachtrijen.

  • Complexe toepassingen. Gebruik meerdere consumentengroepen voor complexe toepassingen waarbij verschillende taken verschillende verwerkingskenmerken en prestatiegaranties vereisen.

Problemen en overwegingen

Houd rekening met de volgende punten wanneer u besluit hoe u dit patroon implementeert:

Algemene aanbevelingen

  • Prioriteiten duidelijk definiëren. Stel afzonderlijke en duidelijke prioriteitsniveaus in die relevant zijn voor uw oplossing. U kunt bijvoorbeeld berichten met hoge prioriteit definiëren als berichten die binnen 10 seconden moeten worden verwerkt. Identificeer de consumentenvereisten voor het verwerken van items met hoge prioriteit en wijs de benodigde resources dienovereenkomstig toe.

  • Gebruikersgroepen dynamisch aanpassen. Schaal de grootte van consumentengroepen op basis van de lengte van de wachtrij die ze onderhouden.

  • De status van de wachtrij bewaken. Houd de diepte van de wachtrij bij, de verwerkingslatentie, het aantal bezorgingen en de doorvoer, zodat u achterstanden en vertragingen kunt detecteren voordat ze van invloed zijn op het werk.

  • Gebruik deadletterwachtrijen. Verplaats problematische berichten na een configureerbaar aantal afleverpogingen naar een dead-letter-wachtrij, zodat één problematisch bericht het prioriteitspad niet blokkeert.

  • Prioriteit geven aan serviceniveaus. Implementeer prioriteitswachtrijen om te voldoen aan bedrijfsbehoeften waarvoor prioriteit moet worden gegeven aan beschikbaarheid of prestaties. Klanten met hoge prioriteit kunnen bijvoorbeeld een hoger serviceniveau ontvangen, zodat ze betere prestaties en beschikbaarheid ervaren.

  • Overweeg verwerking met lage prioriteit. Bepaal of alle items met hoge prioriteit moeten worden verwerkt voor items met een lagere prioriteit. Verhoog indien mogelijk de prioriteit van oude berichten dynamisch om ervoor te zorgen dat berichten met een lage prioriteit uiteindelijk worden verwerkt.

  • Kosten optimaliseren en minimaliseren. Kritieke taken onmiddellijk uitvoeren met beschikbare resources. Plan minder kritieke achtergrondtaken tijdens minder drukke tijden.

    Als u één wachtrij gebruikt, optimaliseert u de kosten door het aantal consumenten terug te schalen. Berichten met hoge prioriteit worden eerst verwerkt, maar mogelijk langzamer, terwijl berichten met een lagere prioriteit langere vertragingen kunnen ondervinden.

  • Beveilig processors tegen pieken in de vraag. Als de aanvoersnelheid van de producent de verwerkingscapaciteit van de consument kan overschrijden, combineer dit patroon dan met het patroon Queue-Based Load Leveling. Deze benadering buffert verkeerspieken en helpt ervoor te zorgen dat downstreamverwerkingsbronnen overbelast raken.

Aanbevelingen voor meerdere wachtrijen

  • Bewaak de verwerkingssnelheden. Om ervoor te zorgen dat berichten met de verwachte snelheid worden verwerkt, controleert u continu de verwerkingssnelheid van wachtrijen met hoge en lage prioriteit.

  • Preëmptie en onderbreking implementeren. Als u meerdere wachtrijen met één consumentengroep gebruikt, implementeert u een algoritme dat ervoor zorgt dat wachtrijen met hoge prioriteit altijd worden onderhouden vóór wachtrijen met lagere prioriteit.

  • Houd rekening met wachtrijkosten. Houd rekening met de financiële kosten voor het controleren en verwerken van wachtrijen. Sommige wachtrijservices brengen kosten in rekening voor het plaatsen, ophalen en bevragen van berichten. Deze kosten kunnen toenemen met het aantal wachtrijen.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

  • U moet voldoen aan verschillende latentie- of serviceniveaudoelstellingen voor verschillende werkklassen, zoals Premium versus Standard-klantaanvragen.

  • Werk komt met pieken binnen en u moet kritieke processen beschermen door berichten met hoge prioriteit eerst te verwerken en werk met lagere prioriteit uit te stellen.

Dit patroon is mogelijk niet geschikt wanneer:

  • Alle werkitems hebben een vergelijkbaar zakelijk belang en strikte FIFO-verwerking is belangrijker dan planning op basis van prioriteit.

  • Taken hebben sterke rangschikkingsafhankelijkheden voor prioriteitsniveaus en het opnieuw ordenen van werk op prioriteit kan inconsistente resultaten veroorzaken of complexe coördinatielogica vereisen.

Ontwerp van werkbelasting

Evalueer hoe u het patroon Priority Queue gebruikt in het ontwerp van een workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van elke pijler ondersteunt.

Pijler Hoe dit patroon ondersteuning biedt voor pijlerdoelen
Beslissingen over betrouwbaarheidsontwerp helpen uw workload bestand te worden tegen storingen en ervoor te zorgen dat deze herstelt naar een volledig functionerende status nadat er een fout is opgetreden. Door items te scheiden op basis van bedrijfsprioriteit kunt u de betrouwbaarheidsinspanningen richten op het meest kritieke werk.

- RE:02 Kritieke stromen
Prestatie-efficiëntie helpt uw workload efficiënt te voldoen aan de vereisten door middel van optimalisaties in schalen, gegevens en code. Door items te scheiden op basis van bedrijfsprioriteit kunt u zich richten op prestatie-inspanningen voor het meest tijdgevoelige werk.

- PE:09 Kritieke stromen

Als dit patroon compromissen binnen een pijler introduceert, moet u deze tegen de doelstellingen van de andere pijlers overwegen.

Voorbeeld

In het voorbeeld van het patroon Priority Queue op GitHub ziet u een implementatie van het patroon Priority Queue dat gebruikmaakt van Azure Service Bus onderwerpen en abonnementen. In het voorbeeld wordt een beveiligd opslagaccount, een Application Insights-resource voor bewaking en een Service Bus naamruimte geïmplementeerd om communicatie tussen de afzender- en consumentenfuncties mogelijk te maken.

De implementatie bevat drie functie-apps: één afzender en twee consumenten. De consumenten-apps gebruiken verschillende maximumaantal exemplaren om de prioriteit van berichten te simuleren. De funcPriorityQueueConsumerHigh functie kan worden uitgeschaald naar 200 exemplaren, terwijl de funcPriorityQueueConsumerLow functie beperkt is tot 40 exemplaren. Alle functie-apps maken gebruik van het Flex-verbruiksplan en zijn verbonden met Application Insights voor diagnostische gegevens en bewaking.

Roltoewijzingen verlenen beveiligde toegang tot Service Bus en opslag met behulp van beheerde identiteiten. Alle functie-apps delen hetzelfde opslagaccount en Application Insights-resource. Deze configuratie centraliseert waarneembaarheid en logboekregistratie.

In het volgende diagram ziet u de architectuur van de prioriteitswachtrij:

Diagram waarin wordt getoond hoe u een prioriteitswachtrij implementeert met behulp van Service Bus.

In het voorgaande diagram:

  1. Applicatie (producent). De toepassing PriorityQueueSender maakt berichten, wijst aan elk bericht een aangepaste toepassingseigenschap toe genaamd Priority, en stelt de waarde van Priority in op High of Low.

  2. Berichtbroker en onderwerp. De Service Bus berichtbroker verzendt berichten naar één Service Bus onderwerp met de naam messages. Service Bus sql-filters gebruikt om elk bericht te routeren naar het abonnement met hoge prioriteit of lage prioriteit, op basis van de Priority waarde ervan.

  3. Meerdere consumentengroepen. De consumergroepen PriorityQueueConsumerHigh en PriorityQueueConsumerLow reageren op berichten uit de abonnementen met hoge of lage prioriteit met behulp van Service Bus-triggers van Azure Functions.

Rol in voorbeeld Azure service in voorbeeld Naam in voorbeeld
Applicatie (producent) Azure Functions-app PriorityQueueSender
Berichtbroker Azure Service Bus (een cloud-gebaseerde berichtendienst van Microsoft) <de naamruimte van uw Service Bus>
Berichtonderwerp Azure Service Bus-onderwerp messages
Abonnementen op berichten Azure Service Bus abonnementen highPriority
lowPriority
Consumenten Azure Functions-app PriorityQueueConsumerHigh
PriorityQueueConsumerLow

Volgende stappen 

De volgende patronen kunnen nuttig zijn wanneer u dit patroon implementeert:

  • Patroon voor belastingnivellering op basis van een wachtrij: Gebruik een wachtrij als buffer tussen het aannemen van aanvragen en de verwerking. Gebruik dit met het patroon Priority Queue wanneer u zowel burst-beveiliging als gedifferentieerde verwerking nodig hebt.

  • Patroon voor concurrerende consumers: Implementeer meerdere consumers die naar dezelfde wachtrij luisteren en taken parallel verwerken om de doorvoer te verhogen. Slechts één consument verwerkt elk bericht.

  • Beperkingspatroon: Beperking implementeren met behulp van wachtrijen voor het beheren van aanvraagsnelheden. Gebruik prioriteitsberichten om aanvragen van kritieke toepassingen of klanten met een hoge waarde te prioriteren ten opzichte van minder belangrijke toepassingen.