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.

Kommentar

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.

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.

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.

Kommentar

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.

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 via Azure-portalen. 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.

Förfallodatum för sessionsaktiverade entiteter

För sessionsaktiverade köer eller ämnens prenumerationer låses meddelanden på sessionsnivå. Om TTL:n för något av meddelandena upphör att gälla tas alla meddelanden som är relaterade till sessionen antingen bort eller obeställbara baserat på den obemärkta inställningen aktiverad för meddelandeförfalloinställningen på entiteten. Med andra ord, om det finns ett enda meddelande i sessionen som har passerat TTL har alla meddelanden i sessionen upphört att gälla. Meddelandena upphör bara att gälla om det finns en aktiv lyssnare.

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 namnområdet. 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
Kö
  • Inga sändningar
  • Inga mottagningar
  • Inga uppdateringar av kön
  • Inga schemalagda meddelanden
  • Ingen bläddra/kika
Ämnesnamn
  • 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 vidarebefordring i kön eller prenumerationen motsvarar det att en mottagar-peform tas emot i kön eller prenumerationen och att de inte är inaktiva.

SDK:er

Nästa steg

Mer information om Service Bus-meddelanden finns i följande artiklar: