Share via

Azure Service Bus - Verlooptijd van bericht (Time to Live)

  • Artikel

De nettolading in een bericht, of een opdracht of onderzoek dat een bericht aan een ontvanger overbrengt, is bijna altijd onderhevig aan een bepaalde vorm van vervaldatum op toepassingsniveau. Na een dergelijke deadline wordt de inhoud niet meer geleverd of wordt de aangevraagde bewerking niet meer uitgevoerd.

Voor ontwikkel- en testomgevingen waarin wachtrijen en onderwerpen vaak worden gebruikt in de context van gedeeltelijke uitvoeringen van toepassingen of toepassingsonderdelen, is het ook wenselijk dat gestrande testberichten automatisch worden verzameld, zodat de volgende testuitvoering schoon kan worden gestart.

Notitie

Als u nog niet bekend bent met Service Bus-concepten, raadpleegt u Service Bus-concepten en Service Bus-wachtrijen, onderwerpen en abonnementen.

De vervaldatum voor elk afzonderlijk bericht kan worden bepaald door de time-to-live-systeemeigenschap in te stellen, waarmee een relatieve duur wordt opgegeven. De vervaldatum wordt een absoluut moment wanneer het bericht in de entiteit wordt geplaatst. Op dat moment neemt de eigenschap expires-at-utc de waarde enqueued-time-utc + time-to-live. De time-to-live-instelling (TTL) voor een brokered bericht wordt niet afgedwongen wanneer er geen clients actief luisteren.

Notitie

Berichten die zijn verlopen, worden mogelijk niet onmiddellijk verwijderd door de broker. De broker kan ervoor kiezen om deze berichten te laten verlopen, op basis van of de entiteit actief wordt gebruikt op het moment dat een bericht verloopt. Klanten kunnen daarom een onjuist aantal berichten observeren bij het gebruik van het verlopen van berichten en kunnen deze berichten zelfs zien tijdens een korte weergavebewerking. Wanneer u echter berichten ontvangt, wordt het verlopen bericht niet opgenomen.

Voorbij het chatbericht verloopt om utc , worden berichten niet meer in aanmerking komen voor het ophalen. De vervaldatum heeft geen invloed op berichten die momenteel zijn vergrendeld voor bezorging. Deze berichten worden nog steeds normaal verwerkt. Als de vergrendeling verloopt of het bericht wordt afgelaten, wordt de vervaldatum onmiddellijk van kracht. Terwijl het bericht is vergrendeld, is de toepassing mogelijk in het bezit van een bericht dat is verlopen. Of de toepassing bereid is om door te gaan met de verwerking of ervoor kiest om het bericht af te laten, is aan de implementeerfunctie.

Extreem lage TTL in de volgorde van milliseconden of seconden kan ertoe leiden dat berichten verlopen voordat ontvangsttoepassingen deze ontvangen. Houd rekening met de hoogste TTL die geschikt is voor uw toepassing.

Notitie

Voor geplande berichten geeft u het tijdstip op waarop het bericht in de wachtrij moet worden geplaatst om te worden opgehaald. Het tijdstip waarop het bericht naar Service Bus wordt verzonden, verschilt van het tijdstip waarop het bericht wordt verzonden. De verlooptijd van het bericht is afhankelijk van de duur van de enqueued, niet van het tijdstip waarop het bericht naar Service Bus wordt verzonden. Daarom is de vervaldatum-at-utc nog steeds tijd + time-to-live.

Als u bijvoorbeeld de ScheduledEnqueueTimeUtc op 5 minuten en UtcNowTimeToLive op 10 minuten instelt, verloopt het bericht na 5 + 10 = 15 minuten vanaf nu. Het bericht wordt na 5 minuten in de wachtrij geplaatst en de teller van 10 minuten begint vanaf dat moment.

Verloopdatum op entiteitsniveau

Alle berichten die naar een wachtrij of onderwerp worden verzonden, zijn onderhevig aan een standaardverlooptijd die is ingesteld op entiteitsniveau. Deze kan ook worden ingesteld in de portal tijdens het maken en later worden aangepast. De standaardverlooptijd wordt gebruikt voor alle berichten die naar de entiteit worden verzonden, waarbij time-to-live niet expliciet is ingesteld. De standaardverlooptijd fungeert ook als een plafond voor de time-to-live-waarde. Berichten met een langere verlooptijd van time-to-live dan de standaardwaarde worden op de achtergrond aangepast aan de standaardwaarde voor de time-to-live van berichten voordat ze worden gestaakt.

Notitie

  • De standaardwaarde voor time-to-live voor een brokered bericht is de grootst mogelijke waarde voor een ondertekend 64-bits geheel getal als dit niet anders is opgegeven.
  • Voor berichtenentiteiten (wachtrijen en onderwerpen) is de standaardverlooptijd ook het grootst mogelijke waarde voor een ondertekend 64-bits geheel getal voor Service Bus Standard- en Premium-lagen . Voor de Basic-laag is de standaardverlooptijd (ook maximum) 14 dagen.
  • Als in het onderwerp een kleinere TTL wordt opgegeven dan het abonnement, wordt de TTL van het onderwerp toegepast.

Verlopen berichten kunnen optioneel worden verplaatst naar een wachtrij met onbestelbare berichten. U kunt deze instelling programmatisch configureren of de Azure-portal gebruiken. Als de optie uitgeschakeld blijft, worden verlopen berichten verwijderd. Verlopen berichten die naar de wachtrij met dode letters zijn verplaatst, kunnen worden onderscheiden van andere berichten met onbestelbare berichten door de eigenschap dead-letter reason te evalueren die door de broker wordt opgeslagen in de sectie gebruikerseigenschappen.

Als het bericht is beveiligd tegen verlooptijd tijdens het vergrendelen en als de vlag is ingesteld op de entiteit, wordt het bericht verplaatst naar de wachtrij met dode letters wanneer de vergrendeling wordt afbroken of verloopt. Het wordt echter niet verplaatst als het bericht is vereffend, waarbij ervan wordt uitgegaan dat de toepassing het heeft verwerkt, ondanks de nominale vervaldatum. Zie Berichtenoverdrachten, vergrendelingen en afwikkeling voor meer informatie over berichtvergrendelingen en -afwikkeling.

De combinatie van time-to-live en automatische (en transactionele) dead-lettering bij het verlopen is een waardevol hulpmiddel om te bepalen of een taak die aan een handler of een groep handlers onder een deadline wordt gegeven, wordt opgehaald voor verwerking wanneer de deadline wordt bereikt.

Denk bijvoorbeeld aan een website die op betrouwbare wijze taken moet uitvoeren op een geschaalde back-end en die af en toe verkeerspieken ondervindt of wil worden geïsoleerd tegen beschikbaarheidsleveringen van die back-end. In het normale geval pusht de handler aan de serverzijde voor de ingediende gebruikersgegevens de informatie naar een wachtrij en ontvangt vervolgens een antwoord dat de verwerking van de transactie in een antwoordwachtrij bevestigt. Als er een verkeerspiek is en de back-endhandler de achterstallige items niet tijdig kan verwerken, worden de verlopen taken geretourneerd in de wachtrij met dode letters. De interactieve gebruiker kan worden gewaarschuwd dat de aangevraagde bewerking iets langer duurt dan normaal en de aanvraag kan vervolgens in een andere wachtrij worden geplaatst voor een verwerkingspad waarbij het uiteindelijke verwerkingsresultaat per e-mail naar de gebruiker wordt verzonden.

Tijdelijke entiteiten

Service Bus-wachtrijen, -onderwerpen en -abonnementen kunnen worden gemaakt als tijdelijke entiteiten, die automatisch worden verwijderd wanneer ze gedurende een bepaalde periode niet zijn gebruikt.

Automatisch opschonen is handig in ontwikkelings- en testscenario's waarin entiteiten dynamisch worden gemaakt en niet worden opgeschoond na gebruik, vanwege een onderbreking van de test- of foutopsporingsuitvoering. Het is ook handig wanneer een toepassing dynamische entiteiten maakt, zoals een antwoordwachtrij, voor het ontvangen van antwoorden in een webserverproces of in een ander relatief kortstondig object waar het moeilijk is om deze entiteiten betrouwbaar op te schonen wanneer het objectexemplaren verdwijnen.

De functie is ingeschakeld met behulp van de functie voor automatisch verwijderen voor niet-actieve eigenschap op de entiteit. Deze eigenschap wordt ingesteld op de duur waarvoor een entiteit niet-actief (ongebruikt) moet zijn voordat deze automatisch wordt verwijderd. De minimumwaarde voor deze eigenschap is vijf minuten.

Belangrijk

Als u het vergrendelingsniveau CanNotDeletevan Azure Resource Manager instelt op , in de naamruimte of op een hoger niveau, voorkomt u niet dat entiteiten worden AutoDeleteOnIdle verwijderd. Als u niet wilt dat de entiteit wordt verwijderd, stelt u de AutoDeleteOnIdle eigenschap in op DataTime.MaxValue.

Ledigheid

Dit is wat wordt beschouwd als niet-actieve entiteiten (wachtrijen, onderwerpen en abonnementen):

Entity Wat wordt beschouwd als niet-actief
Queue
  • Geen verzendingen
  • Geen ontvangst
  • Geen updates voor de wachtrij
  • Geen geplande berichten
  • Geen bladeren/korte weergave
Onderwerp
  • Geen verzendingen
  • Geen updates voor het onderwerp
  • Geen geplande berichten
  • Geen bewerkingen voor de abonnementen van het onderwerp (zie de volgende rij)
Abonnement
  • Geen ontvangst
  • Geen updates voor het abonnement
  • Er zijn geen nieuwe regels toegevoegd aan het abonnement
  • Geen bladeren/korte weergave

Belangrijk

Als u de installatie voor automatisch doorsturen hebt ingesteld voor de wachtrij of het abonnement, is dat gelijk aan het ontvangen van een ontvanger in de wachtrij of het abonnement en deze niet-actief zijn.

SDK's

Volgende stappen

Zie de volgende artikelen voor meer informatie over Service Bus-berichten: