Dela via

Azure Service Bus – Förfallodatum för meddelanden (time to live)

  • Artikel

Nyttolasten i ett meddelande, eller ett kommando eller en förfrågan som ett meddelande förmedlar till en mottagare, omfattas nästan alltid av någon form av förfallotid på programnivå. Efter en sådan tidsgräns levereras inte längre innehållet eller så körs inte längre den begärda åtgärden. För utvecklings- och testmiljöer där köer och ämnen ofta används i samband med partiella körningar av program eller programdelar är det också önskvärt att strandsatta testmeddelanden samlas in automatiskt så att nästa testkörning kan börja rensas.

Tid att leva och upphör att gälla vid UTC

Förfallodatumet för ett enskilt meddelande kan styras genom att ange egenskapen time-to-live-system , som anger en relativ varaktighet. Förfallodatumet blir ett absolut ögonblick när meddelandet placeras i entiteten. Då tar egenskapen expires-at-utc värdet enqueued-time-utc + time-to-live. TTL-inställningen (time-to-live) för ett asynkroet meddelande tillämpas inte när det inte finns några klienter som lyssnar aktivt.

Kommentar

Meddelanden som har upphört att gälla kanske inte tas bort omedelbart av asynkron meddelandekö. Asynkron meddelandekö kan välja att på ett latt sätt förfalla dessa meddelanden, baserat på om entiteten används aktivt när ett meddelande upphör att gälla. Kunder kan därför observera ett felaktigt antal meddelanden när de använder förfallodatum för meddelanden och kan till och med se dessa meddelanden under en tittåtgärd. Men när du tar emot meddelanden inkluderas inte det utgångna meddelandet.

Efter den förfallna utc-snabben blir meddelanden inte berättigade till hämtning. Förfallodatumet påverkar inte meddelanden som för närvarande är låsta för leverans. Dessa meddelanden hanteras fortfarande normalt. Om låset upphör att gälla eller om meddelandet avbryts börjar förfallodatumet att gälla omedelbart. Även om meddelandet är låst kan programmet ha ett meddelande som har upphört att gälla. Om programmet är villigt att fortsätta med bearbetningen eller väljer att överge meddelandet är upp till implementeraren.

Extremt låg TTL i storleksordningen millisekunder eller sekunder kan leda till att meddelanden upphör att gälla innan mottagarprogram tar emot det. Överväg den högsta TTL som fungerar för ditt program.

Schemalagda meddelanden

För schemalagda meddelanden anger du den kötid då du vill att meddelandet ska materialiseras i kön för hämtning. Tiden då meddelandet skickas till Service Bus skiljer sig från den tidpunkt då meddelandet visas. Förfallotiden för meddelandet beror på den köade tiden, inte på den tid då meddelandet skickas till Service Bus. Därför är expires-at-utc fortfarande enqueued tid + time-to-live.

Om du till exempel anger ScheduledEnqueueTimeUtc till 5 minuter från UtcNowoch TimeToLive till 10 minuter upphör meddelandet att gälla efter 5 + 10 = 15 minuter från och med nu. Meddelandet materialiseras i kön efter 5 minuter och 10-minutersräknaren startar från och med då.

Förfallodatum på entitetsnivå

Alla meddelanden som skickas till en kö eller ett ämne omfattas av en standard förfallotid som anges på entitetsnivå. Den kan också anges i portalen när den skapas och justeras senare. Standardförfallodatumet används för alla meddelanden som skickas till entiteten där time-to-live inte uttryckligen anges. Standardförfallotiden fungerar också som ett tak för time-to-live-värdet. Meddelanden som har en längre time-to-live-förfallotid än standardvärdet justeras tyst till standardvärdet för tid till live-meddelanden innan de sparas.

Expires-at-utc är avsiktligt. Om meddelandet TTL inte har angetts och endast entiteten TTL har angetts är expires-at-utc ett beräknat värde och beräknas inte i sökvägen Peek utan beräknas i sökvägen Ta emot/Peeklock. Om meddelandet har TTL beräknas detta ut-at-utc när meddelandet skickas och lagras. Så i det här fallet returnerar Peek korrekta utfall-at-utc-värden .

Kommentar

  • Standardvärdet för time to live för ett asynkroet meddelande är det största möjliga värdet för ett signerat 64-bitars heltal om inget annat anges.
  • För meddelandeentiteter (köer och ämnen) är standardförfallotiden också största möjliga värde för ett signerat 64-bitars heltal för Service Bus-standard- och premiumnivåer . För den grundläggande nivån är standardtiden (även den högsta) förfallotiden 14 dagar.
  • Om ämnet anger en mindre TTL än prenumerationen tillämpas TTL-ämnet.

Meddelanden som har upphört att gälla kan eventuellt flyttas till en kö med obeställbara meddelanden. Du kan konfigurera den här inställningen programmatiskt eller med hjälp av Azure Portal. Om alternativet är inaktiverat tas meddelanden som upphört att gälla bort. Utgångna meddelanden som flyttas till kön med obeställbara meddelanden kan skiljas från andra meddelanden med obeställbara meddelanden genom att utvärdera den orsaksegenskap med obeställbara bokstäver som mäklaren lagrar i avsnittet med användaregenskaper.

Om meddelandet skyddas från förfallodatum under lås och om flaggan har angetts för entiteten flyttas meddelandet till kön med obeställbara meddelanden när låset avbryts eller upphör att gälla. Det flyttas dock inte om meddelandet har lösts, vilket sedan förutsätter att programmet har hanterat det, trots den nominella förfallotiden. Mer information om meddelandelås och lösning finns i Meddelandeöverföringar, lås och kvittning.

Kombinationen av time-to-live och automatisk (och transaktionell) obeställbara bokstäver vid förfallodatum är ett värdefullt verktyg för att fastställa förtroende för om ett jobb som ges till en hanterare eller en grupp av hanterare under en tidsgräns hämtas för bearbetning när tidsgränsen nås.

Tänk dig till exempel en webbplats som på ett tillförlitligt sätt behöver köra jobb på en skalbegränsad serverdel och som ibland upplever trafiktoppar eller vill isoleras mot tillgänglighetsavsnitt i serverdelen. I det vanliga fallet skickar hanteraren på serversidan för de inskickade användardata informationen till en kö och får därefter ett svar som bekräftar att transaktionen har hanterats i en svarskö. Om det finns en trafiktoppar och serverdelshanteraren inte kan bearbeta sina kvarvarande uppgifter i tid returneras de utgångna jobben i kön med obeställbara meddelanden. Den interaktiva användaren kan meddelas om att den begärda åtgärden tar lite längre tid än vanligt, och begäran kan sedan placeras i en annan kö för en bearbetningssökväg där det slutliga bearbetningsresultatet skickas till användaren via e-post.

Tillfälliga entiteter

Service Bus-köer, ämnen och prenumerationer kan skapas som tillfälliga entiteter, som tas bort automatiskt när de inte har använts under en angiven tidsperiod.

Automatisk rensning är användbart i utvecklings- och testscenarier där entiteter skapas dynamiskt och inte rensas efter användning på grund av ett avbrott i test- eller felsökningskörningen. Det är också användbart när ett program skapar dynamiska entiteter, till exempel en svarskö, för att ta emot svar tillbaka till en webbserverprocess eller till ett annat relativt kortlivat objekt där det är svårt att på ett tillförlitligt sätt rensa dessa entiteter när objektinstansen försvinner.

Funktionen är aktiverad med hjälp av egenskapen automatisk borttagning på inaktiv i entiteten. Den här egenskapen är inställd på hur länge en entitet måste vara inaktiv (oanvänd) innan den tas bort automatiskt. Minimivärdet för den här egenskapen är 5 minuter.

Viktigt!

Att ställa in Azure Resource Manager-låsnivån CanNotDeletepå , på namnområdet eller på en högre nivå hindrar inte entiteter med AutoDeleteOnIdle från att tas bort. Om du inte vill att entiteten ska tas bort anger du AutoDeleteOnIdle egenskapen till DataTime.MaxValue.

Sysslolöshet

Här är vad som anses vara inaktivitet för entiteter (köer, ämnen och prenumerationer):

Enhet Vad som anses vara inaktivt
Queue
  • Inga sändningar
  • Inga mottagningar
  • Inga uppdateringar av kön
  • Inga schemalagda meddelanden
  • Ingen bläddra/kika
Område
  • Inga sändningar
  • Inga uppdateringar av ämnet
  • Inga schemalagda meddelanden
  • Inga åtgärder för ämnets prenumerationer (se nästa rad)
Prenumeration
  • Inga mottagningar
  • Inga uppdateringar av prenumerationen
  • Inga nya regler har lagts till i prenumerationen
  • Ingen bläddra/kika

Viktigt!

Om du har konfigurerat automatisk vidarebefordran i kön eller prenumerationen motsvarar det att en mottagare utför mottagningar i kön eller prenumerationen och att de inte är inaktiva.

SDK:er

Du kan ange egenskapen time-to-live med hjälp av Software Development Kits (SDK:er).

Relaterat innehåll

Om du inte är bekant med Service Bus-begrepp ännu kan du läsa Service Bus-begrepp och Service Bus-köer, ämnen och prenumerationer.

Mer information om avancerade funktioner i Azure Service Bus finns i Översikt över avancerade funktioner.