Mönster för Scheduler-agentövervakare

Samordna en uppsättning distribuerade åtgärder som en enda logisk åtgärd så att åtgärden som helhet antingen lyckas eller misslyckas. Hantera misslyckanden på ett transparent sätt, annars återställ redan slutfört arbete. Den här metoden ger motståndskraft till distribuerade system genom att återställa från tillfälliga undantag, långvariga fel och processfel som avbryter arbetsflöden med flera steg som orkestreras mellan fjärrtjänster och resurser.

Kontext och problem

Program utför ofta uppgifter som sträcker sig över flera steg, och vissa steg kan anropa fjärrtjänster eller komma åt fjärrresurser under orkestrering av programlogik. Interaktion med allt utanför den lokala processen exponerar uppgiften för en rad olika fellägen. Orkestreringslogik måste hantera dessa fellägen utan att förlora hela åtgärdens integritet.

Du kan hantera enkla situationer, till exempel tillfälliga fel som löser sig på egen hand, med hjälp av metoder som återförsöksmönstret. När felen är mer permanenta, eller om själva orkestreraren fallerar, måste systemet återställa ett konsistent tillstånd utifrån beständiga poster och säkerställa integriteten i den övergripande processen.

Lösning

Scheduler Agent Supervisor-mönstret samordnar en distribuerad aktivitet i flera steg via tre logiska aktörer. Dessa aktörer samordnar de steg som ska utföras som en del av den övergripande uppgiften och hanterar både lyckade och misslyckade körningar.

Scheduler

Scheduler planerar de steg som utgör uppgiften och orkestrerar deras körning. Scheduler ansvarar för att kombinera steg i en pipeline eller ett arbetsflöde och köra dem i rätt ordning. När varje steg fortskrider registrerar Scheduler sitt tillstånd, till exempel steg som inte har startats ännu, stegkörning eller slutfört steg. Tillståndet innehåller också en sluttid som begränsar hur lång tid steget får ta.

När ett steg behöver en fjärrtjänst eller resurs anropar Scheduler en lämplig agent och skickar arbetsinformationen till den. Schemaläggaren kommunicerar vanligtvis med agenterna genom asynkron begär-/svarsmeddelandehantering, ofta implementerad över köer. Du kan använda andra distribuerade meddelandetekniker i stället.

Handläggare

En agent kapslar in ett anrop till en fjärrtjänst eller åtkomst till en fjärrresurs som ett aktivitetssteg refererar till. Varje agent omsluter vanligtvis anrop till en enda tjänst eller resurs och implementerar lämplig felhanterings- och återförsökslogik inom den fullständiga tid som Scheduler inför. När omförsökslogik används skickar agenten en stabil identifierare för alla återförsök. En underordnad tjänst kan använda detta för deduplicering.

Om olika steg i arbetsflödet använder olika tjänster eller resurser kan varje steg referera till en annan agent. Den mappningen är en implementationsdetalj i mönstret. Vägledning om hur du utformar återförsöksstrategier finns i Metodtips för tillfällig felhantering.

Arbetsledare

Övervakaren övervakar statusen för de steg som Scheduler utför. Supervisor körs periodiskt med den frekvens som arbetslasten anger och undersöker statusen för steget som Scheduler registrerade. Om övervakaren hittar steg som har överskridit tidsgränsen eller misslyckats ordnas det så att lämplig agent kan återställa steget, eller så utlöser det en annan åtgärd som kan innefatta att ändra stegstatusen. Övervakaren begär endast dessa återställningsåtgärder. Schemaläggaren och agenterna implementerar dem.

Interaktioner

Scheduler, Agent och Supervisor är logiska komponenter och deras fysiska implementering beror på vilken teknik du använder. Du kan till exempel implementera flera logiska Agenter som en del av en enda webbtjänst eller som aktiviteter i samma värdbaserade arbetsprocess.

Scheduler underhåller aktivitetsförloppet och tillståndet per steg i ett beständigt datalager som kallas tillståndslagret. Övervakaren använder den här informationen för att avgöra om ett steg misslyckades. Följande diagram visar sambandet mellan schemaläggaren, agenterna, supervisorn och tillståndslagret.

• Scheduler organiserar och kör de steg som utgör uppgiften som ett arbetsflöde.
• Ett steg i arbetsflödet kan skicka en begäran till en agent om att få åtkomst till en fjärrresurs eller anropa en fjärrtjänst. Begäranden och svar skickas vanligtvis asynkront.
• En agent får åtkomst till fjärrresursen eller tjänsten. Agenten bör innehålla felhantering och logik för återförsök.
• Schemaläggaren upprätthåller statusen för varje steg i tillståndslagret när det påbörjas och slutförs.
• Supervisor övervakar status för steg i tillståndslagret och kan begära att statusen för ett steg uppdateras.
• Övervakaren begär att Scheduler försöker utföra ett misslyckat steg igen.

När programmet är redo att köra en uppgift skickar det en begäran till Scheduler. Scheduler registrerar inledande tillstånd för uppgiften och dess steg, till exempel steg som inte har startats ännu, i tillståndsarkivet och börjar sedan köra de åtgärder som arbetsflödet definierar. När Schedulern startar varje steg uppdaterar den stegets tillstånd, till exempel steg körs, i tillståndslagret.

Om ett steg refererar till en fjärrtjänst eller fjärransluten resurs skickar Scheduler ett meddelande till lämplig agent. Meddelandet innehåller den information som agenten behöver för att anropa tjänsten eller komma åt resursen, tillsammans med den fullständiga tiden och återförsöksersättningen för åtgärden.

En agent kan implementera den logik för återförsök som är lämplig för dess arbete, men om agenten inte slutför sitt arbete inom den fullständiga tiden förutsätter Scheduler att åtgärden misslyckades och slutar vänta på ett svar. Agenten måste respektera tidsgränsen och får inte starta nya bieffekter efter att tiden har löpt ut, även om arbete som redan pågår kan fortsätta.

Om agenten slutför åtgärden returneras ett svar till Scheduler. Scheduler uppdaterar tillståndet för att till exempel slutföra steget och påbörjar nästa steg. Den här processen fortsätter tills hela uppgiften har slutförts.

Scheduler måste ignorera alla sena svar och agenten får inte försöka återställa arbetsflödet på egen hand. Om själva agenten misslyckas får Scheduler inte heller något svar. Statusen i tillståndsarkivet skiljer inte avsiktligt ett steg som överskrider en tidsgräns från ett steg som misslyckas.

När ett steg överskrider tidsgränsen eller misslyckas anges steget i posten i tillståndslagret fortfarande som running, men med en passerad sista slutförandetid. Supervisor söker efter poster i det här tillståndet och ombesörjer återställning.

Övervakaren måste också förhindra att samma steg återförsöks i all oändlighet. Övervakaren upprätthåller ett återförsöksantal för varje steg tillsammans med tillståndsinformationen i tillståndsarkivet. Om antalet överskrider ett fördefinierat tröskelvärde kan Supervisor konfigureras att vänta under en längre period innan Scheduler ombeds att försöka köra steget igen, om det underliggande felet avhjälps under den tiden.

En möjlig strategi för Supervisor är att förlänga värdet för slutförandetid och skicka ett meddelande till Scheduler som identifierar det steg vars tidsgräns överskreds, så att Scheduler kan försöka köra det igen. Den här designen kräver att steglogik är idempotent, eftersom samma arbete kan utföras mer än en gång.

Alternativt kan övervakaren be Schemaläggaren att ångra hela aktiviteten genom att utlösa en kompenserande transaktion. Den här metoden beror på att Scheduler och agenter tillhandahåller tillräckligt med information för att implementera kompenserande åtgärder för varje steg som redan har slutförts. Kompensationsloggen behöver vara ordnad samt beständig, eftersom kompensationsåtgärder vanligtvis körs i omvänd ordning jämfört med de steg som slutfördes. En kompenserande åtgärd som misslyckas lämnar uppgiften i ett tillstånd som varken har slutförts eller ångrats. Tillståndslagret måste kunna representera detta tillstånd så att operatörer kan lokalisera och utreda det.

I en faktisk implementering av det här mönstret kan flera instanser av Scheduler köras samtidigt, var och en hanterar en delmängd av uppgifter. Systemet kan också köra flera instanser av varje agent eller flera övervakare. När fler än en övervakare är aktiv måste övervakarna samordna så att de inte konkurrerar om att återställa samma misslyckade steg eller uppgift. Valmönstret för ledare är ett sätt att samordna övervakare.

Den största fördelen med det här mönstret är att systemet förblir motståndskraftigt mot både tillfälliga och oåterkalleliga fel, och du kan bygga det till självåterställning. Om en agent eller Scheduler misslyckas kan du starta en ny instans och övervakaren kan ordna så att den berörda aktiviteten återupptas. Om själva övervakaren fallerar kan en annan instans ta över där den föregående instansen slutade. När Supervisor körs enligt schema startar en ny instans automatiskt vid nästa intervall. Du kan också replikera tillståndslagret för ökad resiliens.

Problem och överväganden

Tänk på följande när du bestämmer hur du ska implementera det här mönstret:

• Implementeringskomplexitet. Det här mönstret är svårt att implementera och kräver noggrann testning av varje felläge som systemet kan uppleva. Planera för felinmatningstestning tillsammans med funktionell testning.

• Försök att förstärka igen. Oberoende återförsöksgränser i lagren Agent, orchestration runtime, client library, messaging och Supervisor multiplicerar antalet anrop till ett beroende som inte fungerar. Ange Scheduler som ägare till en varaktig budget för återförsök från slutpunkt till slutpunkt och konfigurera eller inaktivera återförsök i de andra lagren så att deras sammanlagda maxvärde inte kan överskrida budgeten.

• Antagningskontroll. Mönstret begränsar inte hur mycket arbete som kan utföras samtidigt. Eftersom Scheduler är byggd för att aldrig förlora arbete som den accepterar, skapar en långsam eller misslyckad nedströmstjänst en växande population av bearbetningsposter i stället för synligt bakåttryck för inskickaren. Vägen för inskickning behöver en egen belastningskontroll, till exempel en begränsad kö, ett tak för samtidiga pågående uppgifter eller att nya inskick avvisas när antalet väntande uppgifter överstiger ett tröskelvärde. Den här backpressuren hjälper till att säkerställa att en incident längre nedströms inte obemärkt orsakar en obegränsad eftersläpning i tillståndslagret.

• Beständighet för återställningsläge. Scheduler-återställnings- och återförsökslogik är komplex och beror på tillståndet i tillståndsarkivet. Du kan också behöva registrera den information som krävs för att köra en kompenserande transaktion i ett beständigt lager, och själva den kompenserande transaktionen kan misslyckas. Behandla tillståndslagret och eventuell logg för kompenserande transaktioner som förstklassiga beständiga tillgångar. Dessa tillgångar måste överleva Scheduler, agenterna och övervakaren, och de måste kunna återställas oberoende av de arbetare som skriver till dem.

  Viktigt!

  Kompensationsloggen måste ärva dataklassificeringen för de data som den behöver spåra. Om ett steg accepterar kund- eller betalningsdata ärver den kompenserande transaktionsloggen den känsligheten och de tillhörande kvarhållningsreglerna.

• Problem med dubbelskrivning. Att skicka in en uppgift innebär vanligtvis fler än en beständig skrivoperation. En uppgift kan till exempel behöva skriva både en ansökningspost i en verksamhetsdatabas och en första post i tillståndslagret. De här skrivningarna ingår inte i samma transaktion, så om bara en skrivning genomförs kanske en programpost inte har någon post i tillståndslagret, eller så kanske en post i tillståndslagret inte har någon programpost. Det aktuella mönstret löser inte det här dubbelskrivningsproblemet. Vanliga lösningar är att skriva i en varaktig orkestrering med en kompenserande borttagning vid fel, tillämpa mönstret Transaktionell utkorg eller använda en stabil identifierare, till exempel programmets eget uppgifts-ID för att göra varje skrivning på ett säkert sätt repeterbar.

• Versionshantering av arbetsflöden och tillstånd. Långvariga processer kan sträcka sig över driftsättningar, så ändringar i logiken i arbetsflöden eller i sparat tillstånd kan förhindra omspelning, återställning eller kompensation för pågående arbete. Versionshantera båda kontrakten och behåll kompatibel kod och tillståndshantering tills ingen aktiv uppgift är beroende av dem.

• Kompensationsresultat. En kompenserande transaktion kan slutföras, misslyckas eller stoppas delvis. Tillståndsdatorn som Scheduler underhåller måste representera alla dessa tillstånd. Om Fel är det enda sluttillståndet ser en kompensation som har fastnat likadan ut som ett steg som misslyckades innan kompensationen kördes, och operatörerna förlorar den signal de behöver för att kunna ingripa. Skilj mellan kompensation pågår, kompensation slutförd och kompensation misslyckad i tillståndslagrets schema i stället för att slå ihop dem till ett enda feltillstånd.

• Övervakarens kadens. Hur ofta Supervisor ska köras är en medveten avvägning. Den bör köras tillräckligt ofta för att misslyckade steg eller steg som har överskridit tidsgränsen inte ska blockera arbetet under en längre period, men inte så ofta att den orsakar belastning på och kostnader för tillståndslagret. Justera intervallet mot den typiska stegvaraktigheten och den acceptabla identifieringsfördröjningen för ett fast steg och gå tillbaka till det när arbetsflödesvolymen växer.

• Steg-idempotens. En agent kan komma att utföra ett steg mer än en gång. Övervakaren kan till exempel förlänga tidsfristen för slutförande och be Schemaläggaren att försöka köra om ett steg vars ursprungliga körning redan fick effekt, utan att Schemaläggaren någonsin såg det. Därför måste logiken som implementerar varje steg vara idempotent.

• Driftssynlighet. Mönstrets körningsbeteende ligger i övergångar i tillståndslagret snarare än i synkrona responser. Operatörer kan bara se vad tillståndsarkivet och arbetarna genererar. Bestäm vad Scheduler, Agenter och Övervakare ska generera och vilka tröskelvärden som ska utlösa aviseringar.

• Omstart och återställning av Scheduler. Om Scheduler startas om efter ett fel, eller om arbetsflödet som Scheduler kör oväntat avslutas, måste Scheduler kunna fastställa statusen för alla aktiviteter som den hanterade när den misslyckades och återuppta aktiviteten från den tidpunkten. Implementeringsinformationen för den här återställningen är vanligtvis systemspecifik. Till exempel kan en Scheduler som bygger på en orkestreringsmotor med stöd för kontrollpunkter förlita sig på att körningsmiljön spelar upp historiken och återupptar körningen, medan en anpassad Scheduler själv måste återskapa det pågående tillståndet från tillståndslagret. Om en uppgift inte kan återställas kan det arbete som redan har utförts för den uppgiften behöva ångras, vilket kan kräva en kompenserande transaktion.

När du ska använda det här mönstret

Använd det här mönstret i sådana här scenarier:

• En process körs i en distribuerad arbetsbelastning och måste förbli motståndskraftig mot både kommunikationsfel och driftsfel i de tjänster och resurser som den samordnar.

• Bakgrundsjobb orkestrerar flerstegsarbetsflöden vars steg involverar fjärrtjänster eller resurser, och arbetsflödena i sin helhet måste antingen slutföras eller rullas tillbaka på ett korrekt sätt. Vanliga exempel är orderbearbetning och resursetablering. Mer information finns i Metodtips för bakgrundsjobb.

Det här mönstret kanske inte är lämpligt när:

• Uppgiften anropar inte fjärrtjänster eller åtkomst till fjärrresurser. Det finns ingen distribuerad felyta för rollerna Scheduler, Agent och Supervisor att minimera. Mönstrets samordningskostnader medför kostnader utan återhämtningsfördelar.

Design av arbetsbelastning

Utvärdera hur du använder Scheduler Agent Supervisor-mönstret i en arbetsbelastnings design för att hantera de mål och principer som beskrivs i Azure Well-Architected Framework-pelarna. Följande tabell innehåller vägledning om hur det här mönstret stöder målen för varje pelare.

Om detta mönster inför kompromisser inom en pelare bör du överväga dem mot målen för de andra pelarna.

Exempel

Det här exemplet distribuerar ett webbprogram som implementerar ett e-handelssystem på Microsoft Azure. Användare bläddrar bland produkter och gör beställningar via ett webbgränssnitt, och bakgrundsprocesserna i orderbearbetningsflödet anropar en fjärrtjänst som är känslig för övergående och mer långvariga fel. Orderbearbetning implementerar Scheduler Agent Supervisor-mönstret med hjälp av Durable Functions, Azure Service Bus och Azure Cosmos DB.

En inlämningsaktivitet skriver till orderdatabasen och ett tillståndslager i Cosmos DB, en Durable Functions-orkestrerare tar hand om väntande tillståndsposter och skickar uppgifter till en agent via ett par begärande- och svarsköer i Service Bus, och en övervakningsprocess genomsöker tillståndslagret efter utgångna CompleteBy-tider.

Följande diagram visar en översikt över Azure lösning.

1. Applikationen skickar en förfrågan till en kö för att hantera ordern.
2. Inskickningsprocessen hämtar förfrågningar, lägger in orderuppgifter i orderdatabasen och genererar en post för ordern i tillståndslagret.
3. Schemaläggaren söker efter en order med LockedBy satt till null i tillståndslagret, och arbetsflödeslogiken i Schemaläggaren hanterar ordern.
4. Arbetsflödeslogik skickar begäranden till och tar emot svar från agenter via meddelandeköer.
5. Arbetsflödesuppgifter använder agenter för att anropa fjärrtjänsten.
6. Övervakaren söker efter beställningar med ett utgånget CompleteBy värde och uppdaterar det här värdet så att Scheduler kan försöka igen.

Inlämning

När en kund gör en beställning skickar webbklientdelen ett ordermeddelande till en Service Bus kö. En inskicksfunktion tar emot meddelandet i PeekLock-läge, infogar orderinformationen i orderdatabasen och skapar en post i tillståndslagret för orderprocessen.

Eftersom orderdatabasen och databasen som skapas med Azure Cosmos DB är olika resurser och inte delar en transaktion behandlar funktionen varje skrivning som oberoende idempotent. Funktionen använder order-ID:t som en stabil nyckel, skapar antingen post när den saknas och accepterar en befintlig post först efter att ha verifierat att dess oföränderliga orderdata matchar meddelandet. Motstridiga data gör att funktionen kan ta bort meddelandet och varna en operatör i stället för att skriva över en post.

Posten innehåller följande fält:

När inskicksaktiviteten först skriver posten kopierar den OrderID från den nya beställningen, ställer in LockedBy och CompleteBy på null, ställer in ProcessState på Pending och ställer in FailureCount på 0.

Scheduling

Scheduler är en Durable Functions-orchestrator. En startfunktion avsöker Azure Cosmos DB efter poster där LockedBy är null och ProcessState är Pending. Funktionen skapar ett försöksspecifikt orkestreringsinstans-ID från OrderID och nästa försöksnummer. En villkorlig uppdatering anger ProcessState till Processing och LockedBy till det instans-ID:t innan startprogrammet schemalägger orkestreringen. Det här anspråket hindrar två starter från att schemalägga samma försök.

Varje uppdatering från orkestreringen verifierar också att LockedBy fortfarande matchar instans-ID:t. Den här kontrollen förhindrar att ett försök som har upphört att gälla ändrar tillståndet för ett ersättningsförsök. Parallellism mellan order uppstår genom att många orkestreringsinstanser körs samtidigt, inte genom parallellism inom en enskild order. Orkestreringen anger CompleteBy och styr arbetsflödet.

Orchestrator hämtar orderinformationen från orderdatabasen och kör arbetsflödet som en sekvens med aktivitetsfunktioner. När ett steg behöver en fjärrtjänst anropar det en agent.

Execution

Agenten kan vara en aktivitetsfunktion när arbetet är kortvarigt och körs i samma funktionsapp, eller så kan den vara en separat arbetsprocess som nås via ett par Service Bus-köer för begäran och svar när den körs i en annan körningsmiljö eller över en förtroendegräns. I båda fallen låter orkestratorn en beständig timer tävla mot agentens svar för att upptäcka tidsgränsen CompleteBy.

När agenten nås via Service Bus tar en köutlöst funktion emot svaret och använder Durable Functions-klienten för att skapa en extern händelse som innehåller orkestreringsinstans-ID och ett stabilt händelse-ID. Orchestrator deduplicerar externa händelser genom att aktivera dubblettidentifiering och ange ett stabilt MessageId för varje begäran, så Service Bus kan ta bort dubbletter som introduceras genom återförsök.

Om agenten tar emot ett svar från fjärrtjänsten innan den varaktiga timern utlöses returnerar agenten resultatet till orkestratorn. Orkestratorn slutför steget och uppdaterar ProcessState till Processed endast om LockedBy fortfarande identifierar den aktuella orkestreringen. Om timern utlöses först behandlar orkestreraren steget som misslyckat, slutar vänta och slutförs utan att ändra tillståndsposten.

Agenten slutar på ett kontrollerat sätt att starta nya bieffekter efter sin egen deadline, men arbete som redan pågår kan fortsätta. State-store-posten förblir sedan i tillståndet Processing med ett utgånget värde CompleteBy, vilket gör att Supervisor kan hantera återställningen. Använd idempotens eller en fencing-token som upprätthålls av målet för att förhindra att ett överlappande försök orsakar duplicering av eller konflikt med en sidoeffekt.

Om agenten identifierar ett oåterkalleligt, icke-tillfälligt fel vid kontakt med fjärrtjänsten returneras ett felsvar till orkestratorn. Dirigeraren ställer in ProcessState till Error och genererar en händelse som aviserar en operator, som kan undersöka felet och skicka det misslyckade bearbetningssteget igen.

Övervakning

Supervisorn söker regelbundet i Azure Cosmos DB:s tillståndslager efter ordrar med statusen Processing där CompleteBy har löpt ut. Eftersom OrderID är partitionsnyckeln når den här frågan varje fysisk partition även när ProcessState och CompleteBy indexeras. Processen begränsar varje genomsökning efter ett CompleteBy tidsfönster, ett maximalt resultatantal och fortsättningstokenväxling och övervakar ru-avgiften (request unit).

Större arbetsbelastningar har ett separat återställningsindex eller en separat kö som är partitionerad för övervakarens åtkomstmönster. När Supervisor hittar en utgången post använder den en villkorad uppdatering som verifierar det utgångna värdet för LockedBy innan den ökar FailureCount. Om FailureCount är under ett konfigurerat tröskelvärde återställer Övervakaren LockedBy till null, uppdaterar CompleteBy med en ny utgångstid och ställer tillbaka ProcessState till Pending, vilket gör att startprogrammet kan schemalägga ett nytt försök. Om FailureCount överskrider tröskelvärdet behandlar övervakaren felet som icke-tillfälligt, anger ProcessState till Erroroch genererar en händelse som aviserar en operator.

Statusrapportering

Orkestratorn kan också behöva hålla applikationen som skickade in ordern uppdaterad om förloppet och den slutliga statusen, vilket inte visas i diagrammet. Programmet och orkestratorn frikopplas avsiktligt. Programmet vet inte vilken orkestreringsinstans som hanterar beställningen och orkestreringen vet inte vilken programinstans som publicerade den. På grund av den här avkopplingen kan orkestratorn inte returnera förloppsuppdateringar synkront.

För att rapportera tillbaka orderstatus tillhandahåller varje avsändande applikation sin egen privata, åtkomstkontrollerade svarskö i Service Bus. Begäran som skickas till inskicksaktiviteten innehåller identifieraren för kön, vilken inskicksaktiviteten registrerar i orderns tillståndslager så att orkestreraren kan skicka till rätt kö i stället för att sända till alla. Orkestreraren publicerar sedan statusmeddelanden som mottagen begäran, slutförd order eller beställningen misslyckades i kön, inklusive OrderID så att programmet kan korrelera varje meddelande med den ursprungliga begäran.

Stödjande teknologier

Mappa mönstrets logiska roller till tjänster som passar ditt arbetsflöde och dina driftkrav:

• Scheduler: Använd Durable Functions för kod-första orkestrering eller Azure Logic Apps för visuella arbetsflöden och anslutningsbaserad integrering.

• Agentmeddelanden: Använd Service Bus köer för asynkrona begärande- och svarsmeddelanden.

• Tillståndsarkiv: Använd Azure Cosmos DB för dokumenttillstånd eller Azure SQL Database för relationstillstånd och transaktioner mellan poster.

• Övervakare: Använd en timerutlösare i Functions för lättviktiga genomsökningar eller ett jobb i Container Apps när du behöver en containerkörmiljö.

• Kompensationslogg: Lagra kompensationsposter tillsammans med aktivitetstillstånd eller i Azure Table-lagring eller Blob Storage.

Nästa steg

• Välj mellan Azure Functions och Azure Logic Apps för arbetsflödesorkestrering.
• Version Durable Functions orkestreringar för att skydda arbetsflöden under drift under distributioner.
• Förhindra meddelandeförlust och duplicerad bearbetning i Azure Service Bus genom att kombinera meddelandeavräkning, idempotens och hantering av obeställbara meddelanden.

Relaterade resurser

Följande mönster kan också vara relevanta när du implementerar det här mönstret:

• Återförsöksmönster. En agent kan använda det här mönstret för att transparent försöka utföra en åtgärd som har åtkomst till en fjärrtjänst eller resurs och som tidigare misslyckades. Använd den när orsaken till felet förväntas vara tillfällig och kan korrigeras genom ett nytt försök.

• Mönstret för kretsbrytare. En agent som ansluter till en fjärrtjänst eller resurs kan använda det här mönstret för att hantera fel som tar en varierande tid att korrigera, så upprepade anrop staplas inte mot ett beroende som sannolikt inte svarar.

• Kompenserande transaktionsmönster. Om en Scheduler inte kan slutföra sitt arbetsflöde kan det arbete som redan utförts behöva ångras. Mönstret för kompenserande transaktioner beskriver hur detta arbete kan ångras för operationer som följer modellen för eventual consistency, vilket är vanligt i de långvariga affärsprocesser som en Scheduler samordnar.

• Mönstret för val av ledare. När flera övervakarinstanser körs samtidigt måste de samordnas så att de inte konkurrerar om att återställa samma misslyckade steg. Mönstret Val av ledare beskriver hur man väljer en enda samordnare för det arbetet.