Overzicht van wachtrijen met dead-letter van Service Bus
Azure Service Bus-wachtrijen en onderwerpabonnementen bieden een secundaire submap, een wachtrij met dode letters (DLQ). De wachtrij met onbestelbare berichten hoeft niet expliciet te worden gemaakt en kan niet worden verwijderd of onafhankelijk van de hoofdentiteit worden beheerd.
In dit artikel worden wachtrijen met dode letters in Service Bus beschreven. Veel van de discussie wordt geïllustreerd door het voorbeeld van wachtrijen voor dode letters op GitHub.
De wachtrij met dode letters
Het doel van de wachtrij met onbestelbare berichten is berichten te bewaren die niet kunnen worden bezorgd bij een ontvanger of berichten die niet kunnen worden verwerkt. Berichten kunnen vervolgens worden verwijderd uit de DLQ en geïnspecteerd. Een toepassing kan, met behulp van een operator, problemen corrigeren en het bericht opnieuw indienen, het feit dat er een fout is opgetreden, vastleggen en corrigerende actie ondernemen.
Vanuit het perspectief van een API en protocol is de DLQ meestal vergelijkbaar met elke andere wachtrij, behalve dat berichten alleen kunnen worden verzonden via de bewerking voor onbestelbare letters van de bovenliggende entiteit. Bovendien wordt time-to-live niet waargenomen en kunt u een bericht van een DLQ niet doodmaken. De wachtrij met dead-letter biedt volledige ondersteuning voor peek-lock-levering en transactionele bewerkingen.
De DLQ wordt niet automatisch opgeschoond. Berichten blijven in de DLQ totdat u ze expliciet ophaalt uit de DLQ en het onbestelbare bericht voltooit.
Aantal DLQ-berichten
Het is niet mogelijk om het aantal berichten in de wachtrij met dode letters op onderwerpniveau te verkrijgen. Dat komt doordat berichten niet op onderwerpniveau zitten. Wanneer een afzender een bericht naar een onderwerp verzendt, wordt het bericht binnen milliseconden doorgestuurd naar abonnementen voor het onderwerp en bevindt het zich dus niet meer op onderwerpniveau. U kunt dus berichten zien in de DLQ die is gekoppeld aan het abonnement voor het onderwerp. In het volgende voorbeeld laat Service Bus Explorer zien dat er momenteel 62 berichten zijn in de DLQ voor het abonnement 'test1'.
U kunt ook het aantal DLQ-berichten ophalen met behulp van de Azure CLI-opdracht: az servicebus topic subscription show.
Berichten verplaatsen naar de DLQ
Er zijn verschillende activiteiten in Service Bus die ertoe leiden dat berichten vanuit de berichtenengine zelf naar de DLQ worden gepusht. Een toepassing kan ook expliciet berichten naar de DLQ verplaatsen. De volgende twee eigenschappen (reden voor dode letter en beschrijving van dode letters) worden toegevoegd aan berichten met dode letters. Toepassingen kunnen hun eigen codes definiëren voor de redeneigenschap voor dode letters, maar het systeem stelt de volgende waarden in.
| Reden voor dode letter | Beschrijving van fout met dode letter |
|---|---|
HeaderSizeExceeded |
Het quotum voor de grootte voor deze stream is overschreden. |
TTLExpiredException |
Het bericht is verlopen en naar de wachtrij voor onbestelbare berichten verplaatst. Zie de sectie Time to Live voor meer informatie. |
| Sessie-id is null. | Door sessie ingeschakelde entiteit staat geen berichten toe waarvan de sessie-id null is. |
MaxTransferHopCountExceeded |
Het maximum aantal toegestane hops bij het doorsturen tussen wachtrijen is overschreden. Deze waarde is ingesteld op 4. |
MaxDeliveryCountExceeded |
Bericht kan niet worden gebruikt na maximale bezorgingspogingen. Zie de sectie Maximum aantal bezorgingen voor meer informatie. |
Maximum aantal bezorgingen
Er geldt een limiet voor het aantal pogingen om berichten te leveren voor Service Bus-wachtrijen en -abonnementen. De standaardwaarde is 10. Wanneer een bericht is bezorgd onder een peek-lock, maar expliciet is afgebroken of de vergrendeling is verlopen, wordt het aantal bezorgingen op het bericht verhoogd. Wanneer het aantal bezorgingen de limiet overschrijdt, wordt het bericht verplaatst naar de DLQ. De reden van de dode letter voor het bericht in DLQ is ingesteld op: MaxDeliveryCountExceeded. Dit gedrag kan niet worden uitgeschakeld, maar u kunt het maximumaantal leveringen instellen op een groot getal.
Time to live
Wanneer u dead-lettering inschakelt voor wachtrijen of abonnementen, worden alle verlopende berichten verplaatst naar de DLQ. De redencode voor dode letters is ingesteld op: TTLExpiredException.
Uitgestelde berichten worden niet opgeschoond en verplaatst naar de wachtrij met dode letters nadat ze zijn verlopen. Dit is zo ontworpen.
Fouten tijdens het verwerken van abonnementsregels
Als u dead-lettering inschakelt voor filterevaluatieuitzonderingen, worden eventuele fouten die optreden wanneer de SQL-filterregel van een abonnement wordt uitgevoerd, samen met het offending-bericht vastgelegd in de DLQ. Gebruik deze optie niet in een productieomgeving waarin niet alle berichttypen abonnees hebben.
Dead-lettering op toepassingsniveau
Naast de door het systeem geleverde functies voor dode letters kunnen toepassingen de DLQ gebruiken om onaanvaardbare berichten expliciet af te wijzen. Ze kunnen berichten bevatten die niet goed kunnen worden verwerkt vanwege een soort systeemprobleem, berichten die ongeldige nettoladingen bevatten of berichten die geen verificatie uitvoeren wanneer een beveiligingsschema op berichtniveau wordt gebruikt.
U kunt dit doen door de methode ServiceBusReceiver.DeadLetterMessageAsync aan te roepen.
We raden u aan het type uitzondering op te nemen in de DeadLetterReason en de stacktracering van de uitzondering, DeadLetterDescription omdat het eenvoudiger is om de oorzaak van het probleem op te lossen, wat resulteert in berichten met een dode letter. Houd er rekening mee dat dit kan leiden tot een aantal berichten die de quotumlimiet van 256 kB voor de Standard-laag van Azure Service Bus overschrijden, wat verder aangeeft dat de Premium-laag moet worden gebruikt voor productieomgevingen.
Doodletters in scenario's voor automatisch doorsturen
Berichten worden onder de volgende voorwaarden verzonden naar de wachtrij met onbestelbare berichten:
- Een bericht doorloopt meer dan vier wachtrijen of onderwerpen die aan elkaar zijn gekoppeld.
- De doelwachtrij of het doelonderwerp is uitgeschakeld of verwijderd.
- De doelwachtrij of het onderwerp overschrijdt de maximale grootte van de entiteit.
Onbestelbare brieven in verzenden via scenario's
- Als de doelwachtrij of het onderwerp is uitgeschakeld, wordt het bericht verzonden naar een wachtrij met dead letter (TDLQ) van de bronwachtrij.
- Als de doelwachtrij of het doelonderwerp wordt verwijderd, wordt de 404-uitzondering gegenereerd.
- Als de doelwachtrij of entiteit de grootte van de entiteit overschrijdt, wordt het bericht verzonden naar een TDLQ van de bronwachtrij.
Pad naar de wachtrij met dode letters
U kunt toegang krijgen tot de wachtrij met dode letters met behulp van de volgende syntaxis:
<queue path>/$deadletterqueue
<topic path>/Subscriptions/<subscription path>/$deadletterqueue
Onbestelbare berichten verzenden om opnieuw te worden verwerkt
Omdat er waardevolle zakelijke gegevens kunnen zijn in berichten die in de wachtrij voor dode letters terecht zijn gekomen, is het wenselijk dat deze berichten opnieuw worden verwerkt wanneer operators klaar zijn met de omstandigheden waardoor de berichten in de eerste plaats onbestelbaar zijn.
Met hulpprogramma's zoals Azure Service Bus Explorer kunt u berichten handmatig verplaatsen tussen wachtrijen en onderwerpen. Als er veel berichten in de wachtrij voor onbestelbare berichten staan die moeten worden verplaatst, kan code zoals deze in één keer helpen ze allemaal tegelijk te verplaatsen. Operators geven vaak de voorkeur aan een gebruikersinterface, zodat ze problemen kunnen oplossen met welke berichttypen de verwerking is mislukt, van welke bronwachtrijen en om welke redenen, terwijl ze nog steeds batches berichten opnieuw kunnen indienen om opnieuw te worden verwerkt. Hulpprogramma's zoals ServicePulse met NServiceBus bieden deze mogelijkheden.
Volgende stappen
Zie Dead Lettering inschakelen voor een wachtrij of abonnement voor meer informatie over verschillende manieren om de instelling voor het verlopen van berichten te configureren.