Översikt över köer med obeställbara Service Bus-meddelanden

Azure Service Bus-köer och ämnesprenumerationer tillhandahåller en sekundär underkö som kallas för en död-brevkö (DLQ). Kön för obeställbara meddelanden behöver inte uttryckligen skapas och kan inte tas bort eller hanteras oberoende av huvudentiteten.

Den här artikeln beskriver dead letter-köer i Service Bus. Mycket av diskussionen illustreras av detDead-Letter kö-exemplet på GitHub.

Kön med obeställbara meddelanden

Syftet med kön med obeställbara meddelanden är att lagra meddelanden som inte kan levereras till någon mottagare eller meddelanden som inte kunde bearbetas. Meddelanden kan sedan tas bort från DLQ och inspekteras. Ett program kan låta en användare korrigera problem och skicka meddelandet igen.

Från ett API- och protokollperspektiv liknar DLQ mestadels alla andra köer, förutom att meddelanden endast kan placeras via dead-letter-funktionen hos huvudenheten. Dessutom beaktas inte time-to-live, och du kan inte skicka ett meddelande till en DLQ. Kön med obeställbara meddelanden stöder helt vanliga åtgärder, till exempel peek-lock-leverans, ta emot och ta bort samt transaktionsåtgärder.

Det finns ingen automatisk rensning av kön för obeställbara meddelanden. Meddelanden finns kvar i kön för obeställbara meddelanden tills du uttryckligen hämtar dem och slutför det obeställbara meddelandet.

Sökväg till kön med obeställbara meddelanden

Du kan komma åt kön med obeställbara bokstäver med hjälp av följande syntax:

<queue path>/$deadletterqueue
<topic path>/Subscriptions/<subscription path>/$deadletterqueue

I .NET kan du använda FormatDeadLetterPath -metoden.

QueueClient.FormatDeadLetterPath(queuePath)
SubscriptionClient.FormatDeadLetterPath(topicPath, subscriptionName)

Antal DLQ-meddelanden

Det är inte tillämpligt att hämta antalet meddelanden i dödbrevkön på topic-nivå eftersom meddelanden inte finns på topic-nivå. När en avsändare i stället skickar ett meddelande till ett ämne vidarebefordras meddelandet till prenumerationer för ämnet inom millisekunder och finns därför inte längre på ämnesnivå. Så kan du se meddelanden i DLQ som är kopplad till prenumerationen på ämnet. I följande exempel visar Service Bus Explorer att det för närvarande finns 62 meddelanden i DLQ för prenumerationen: test1.

Du kan också få antalet DLQ-meddelanden med hjälp av Azure CLI-kommandot: az servicebus topic subscription show.

Flytta meddelanden till DLQ

Det finns flera aktiviteter i Service Bus som gör att meddelanden skickas till DLQ från själva meddelandemotorn. Ett program kan också uttryckligen flytta meddelanden till DLQ. Följande två egenskaper (orsak till dödförklarat meddelande och beskrivning av dödförklarat meddelande) läggs till dödförklarade meddelanden. Program kan definiera sina egna koder för egenskapen dead-letter reason, men systemet anger följande värden.

Orsak till obeställbara bokstäver	Beskrivning av fel relaterade till dead-letter meddelanden
HeaderSizeExceeded	Storlekskvoten för den här strömmen överskred gränsen.
TTLExpiredException	Meddelandet har gått ut och blev obeställbart. Mer information finns i avsnittet Time to live (Tid att leva ).
Session ID is null.	Sessionsaktiverad entitet tillåter inte ett meddelande vars sessions-ID är null.
MaxTransferHopCountExceeded	Det maximala antalet tillåtna hopp vid vidarebefordran mellan köer överskred gränsen. Det här värdet är inställt på 4.
MaxDeliveryCountExceeded	Meddelandet kunde inte behandlas efter maximalt antal leveransförsök. Mer information finns i avsnittet Maximalt antal leveranser .

Tid att leva

När du aktiverar obeställbara bokstäver i köer eller prenumerationer flyttas alla meddelanden som upphör att gälla till DLQ. Orsakskoden för obeställbara bokstäver är inställd på: TTLExpiredException. Uppskjutna meddelanden kommer inte att rensas och flyttas till kön med obeställbara meddelanden efter att de har gått ut. Det här beteendet är avsiktligt.

Maximalt antal leveranser

Det finns en gräns för antalet försök att leverera meddelanden för Service Bus-köer och prenumerationer. Standardvärdet är 10. När ett meddelande levereras under ett tittlås, men antingen uttryckligen överges eller om låset har upphört att gälla, ökas leveransantalet för meddelandet. När leveransantalet överskrider gränsen flyttas meddelandet till DLQ. Anledningen till meddelandet i DLQ är inställd på: MaxDeliveryCountExceeded. Det här beteendet kan inte inaktiveras, men du kan ange det maximala leveransantalet till ett stort antal.

Fel vid bearbetning av prenumerationsregler

Om du aktiverar dead-letter-hantering vid undantag under filterutvärdering, registreras eventuella fel som inträffar när en prenumerations SQL-filterregel körs i DLQ, tillsammans med det problematiska meddelandet. Använd inte det här alternativet i en produktionsmiljö där du har meddelandetyper som skickas till ämnet, som inte har prenumeranter, eftersom det kan leda till en stor belastning på DLQ-meddelanden. Se därför till att alla meddelanden som skickas till ämnet har minst en matchande prenumeration.

Dödsbrev på applikationsnivå

Förutom systembaserade funktioner för obeställbara bokstäver kan program använda DLQ för att uttryckligen avvisa oacceptabla meddelanden. De kan innehålla meddelanden som inte kan bearbetas korrekt på grund av någon form av systemproblem, meddelanden som innehåller felaktiga nyttolaster eller meddelanden som misslyckas med autentisering när något säkerhetsschema på meddelandenivå används.

I .NET kan du göra det genom att anropa metoden ServiceBusReceiver.DeadLetterMessageAsync.

Vi rekommenderar att du inkluderar typen av undantag i DeadLetterReason och stackspårningen av undantaget i DeadLetterDescription eftersom det gör det enklare att felsöka orsaken till problemet, vilket resulterar i att meddelanden blir obeställbara. Det kan leda till att vissa meddelanden överskrider kvotgränsen på 256 KB för standardnivån för Azure Service Bus. Du kan uppgradera Service Bus-namnområdet från standardnivån till premiumnivån för att ha högre kvoter och gränser.

Obeställbara bokstäver i scenarier med automatisk vidarebefordran

Meddelanden skickas till kön med obeställbara meddelanden under följande villkor:

• Ett meddelande skickas genom fler än fyra köer eller ämnen som är sammanlänkade.
• Målkön eller ämne är inaktiverat eller borttaget.
• Målkön eller ämnet överskrider den maximala storleken för enheten.

Dödfödda meddelanden i skicka-via-scenarier

• Om målkön eller ämnet är inaktiverat skickas meddelandet till kön för överföring av obeställbara meddelanden (TDLQ) i källkön.
• Om målkön eller entiteten överskrider entitetsstorleken skickas meddelandet till en TDLQ i källkön.

Skicka obeställbara meddelanden för att bearbetas på nytt

När du har löst problemet som gjorde att meddelandet hamnade i dödbrevlådan kan du skicka det på nytt till kön eller ämnet för att det ska bearbetas igen. I vissa fall, om det finns många meddelanden i kön med obeställbara meddelanden som behöver flyttas, kan kod som den här hjälpa till att flytta alla på en gång. Operatörer föredrar ofta att ha ett användargränssnitt så att de kan felsöka vilka meddelandetyper som misslyckades med bearbetningen, från vilka källköer och av vilka skäl, samtidigt som de fortfarande kan skicka om batchar med meddelanden som ska bearbetas på nytt.

Tillgängliga verktyg

• Azure Service Bus Explorer möjliggör manuell flyttning av meddelanden mellan köer och ämnen. Det gör att du kan titta igenom listan över meddelanden och skicka dem igen för att bearbetas på nytt. Den är tillgänglig via Azure-portalen, oavsett vilken SDK du använder för att skicka meddelanden.
• ServicePulse med NServiceBus effektiviserar felhanteringen med den här centraliserade instrumentpanelen. Visualisera, gruppera, filtrera och sök fel snabbt, och försök effektivt att skicka om enskilda eller grupperade meddelanden. Tillgänglig för NServiceBus-slutpunkter.
• ServicePulse med MassTransit tillhandahåller en centraliserad instrumentpanel för felhantering. Du kan visualisera, gruppera, filtrera och söka efter fel med hjälp av olika kriterier. Det möjliggör också redigering och återförsök av enskilda meddelanden eller batchförsök av grupper av meddelanden. Tillgänglig för MassTransit-slutpunkter.

Relaterat innehåll

Se Aktivera dödbrevhantering för en kö eller prenumeration för att lära dig mer om olika sätt att konfigurera inställningen för dödbrevhantering vid utgång av meddelanden.