Omówienie kolejek utraconych komunikatów usługi Service Bus

Kolejki i subskrypcje tematów usługi Azure Service Bus udostępniają dodatkową kolejkę nazywaną kolejką utraconych komunikatów (DLQ). Kolejka utraconych komunikatów nie musi być jawnie utworzona. Ponadto nie można jej usunąć ani zarządzać nią niezależnie od obiektu głównego.

W tym artykule opisano kolejki utraconych komunikatów w usłudze Service Bus. Większość dyskusji jest zilustrowana przykładem kolejek Dead-Letter w witrynie GitHub.

Kolejka utraconych komunikatów

Celem kolejki utraconych komunikatów jest wstrzymanie komunikatów, których nie można dostarczyć do żadnego odbiorcy lub komunikatów, których nie można przetworzyć. Komunikaty można następnie usunąć z biblioteki DLQ i sprawdzić. Aplikacja może zezwolić użytkownikowi na rozwiązywanie problemów i ponowne przesłanie komunikatu.

Z punktu widzenia interfejsu API i protokołu biblioteka DLQ jest w większości podobna do dowolnej innej kolejki, z tą różnicą, że komunikaty mogą być przesyłane tylko za pośrednictwem operacji utraconych komunikatów jednostki nadrzędnej. Ponadto czas wygaśnięcia nie jest obserwowany i nie można martwych wiadomości z DLQ. Kolejka utraconych komunikatów w pełni obsługuje normalne operacje, takie jak podgląd dostarczania blokady, odbieranie i usuwanie oraz operacje transakcyjne.

Nie ma automatycznego procesu czyszczenia DLQ. Komunikaty pozostają w kolejce DLQ do momentu ich jawnego pobrania z kolejki DLQ i ukończenia komunikatu utraconego.

Ścieżka do kolejki utraconych komunikatów

Dostęp do kolejki utraconych komunikatów można uzyskać przy użyciu następującej składni:

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

Na platformie .NET można użyć FormatDeadLetterPath metody .

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

Liczba komunikatów DLQ

Uzyskiwanie liczby komunikatów w kolejce utraconych komunikatów na poziomie tematu nie ma zastosowania, ponieważ komunikaty nie znajdują się na poziomie tematu. Zamiast tego, gdy nadawca wysyła wiadomość do tematu, komunikat jest przekazywany do subskrypcji tematu w milisekundach, a tym samym nie znajduje się już na poziomie tematu. W związku z tym komunikaty można zobaczyć w dlQ skojarzonym z subskrypcją tematu. W poniższym przykładzie Eksplorator usługi Service Bus pokazuje, że w dlQ dla subskrypcji "test1" znajduje się obecnie 62 komunikaty.

Liczbę komunikatów DLQ można również uzyskać przy użyciu polecenia interfejsu wiersza polecenia platformy Azure: az servicebus topic subscription show.

Przenoszenie komunikatów do biblioteki DLQ

Istnieje kilka działań w usłudze Service Bus, które powodują wypychanie komunikatów do biblioteki DLQ z poziomu samego aparatu obsługi komunikatów. Aplikacja może również jawnie przenosić komunikaty do biblioteki DLQ. Następujące dwie właściwości (przyczyna śmierci i opis utraconych komunikatów) są dodawane do wiadomości utraconych. Aplikacje mogą definiować własne kody właściwości przyczyny utraconych komunikatów, ale system ustawia następujące wartości.

Time to live (Czas wygaśnięcia)

Po włączeniu utraconych komunikatów w kolejkach lub subskrypcjach wszystkie wygasające komunikaty są przenoszone do biblioteki DLQ. Kod przyczyny utraconych komunikatów jest ustawiony na: TTLExpiredException. Odroczone komunikaty nie zostaną przeczyszczone i przeniesione do kolejki utraconych wiadomości po ich wygaśnięciu. Wynika to z ustawienia fabrycznego.

Maksymalna liczba dostaw

Istnieje limit liczby prób dostarczenia komunikatów dla kolejek i subskrypcji usługi Service Bus. Wartość domyślna to 10. Za każdym razem, gdy komunikat jest dostarczany w ramach zaglądania blokady, ale jest jawnie porzucony lub blokada wygasła, liczba dostarczania komunikatu jest zwiększana. Gdy liczba dostaw przekroczy limit, komunikat zostanie przeniesiony do biblioteki DLQ. Przyczyna utraconych komunikatów w dlQ jest ustawiona na: MaxDeliveryCountExceeded. Tego zachowania nie można wyłączyć, ale można ustawić maksymalną liczbę dostarczania na dużą liczbę.

Błędy podczas przetwarzania reguł subskrypcji

Jeśli włączysz obsługę utraconych komunikatów dotyczących wyjątków oceny filtru, wszelkie błędy występujące podczas wykonywania reguły filtru SQL subskrypcji są przechwytywane w dlQ wraz z komunikatem o błędzie. Nie używaj tej opcji w środowisku produkcyjnym, w którym masz typy komunikatów wysyłane do tematu, które nie mają subskrybentów, ponieważ może to spowodować duże obciążenie komunikatów DLQ. W związku z tym upewnij się, że wszystkie komunikaty wysyłane do tematu mają co najmniej jedną zgodną subskrypcję.

Nieaktywne tworzenie komunikatów na poziomie aplikacji

Oprócz funkcji tworzenia komunikatów utraconych przez system aplikacje mogą jawnie odrzucać niedopuszczalne komunikaty za pomocą biblioteki DLQ. Mogą one zawierać komunikaty, których nie można prawidłowo przetworzyć z powodu dowolnego rodzaju problemu z systemem, komunikatów, które przechowują źle sformułowane ładunki lub komunikaty, które kończą się niepowodzeniem uwierzytelniania, gdy jest używany jakiś schemat zabezpieczeń na poziomie komunikatu.

Na platformie .NET można to zrobić, wywołując metodę ServiceBusReceiver.DeadLetterMessageAsync.

Zalecamy uwzględnienie typu wyjątku w DeadLetterReason elemecie i ślad stosu wyjątku w DeadLetterDescription obiekcie , ponieważ ułatwia rozwiązywanie problemu, co powoduje, że komunikaty są nieaktywne. Należy pamiętać, że może to spowodować przekroczenie limitu przydziału 256 KB dla warstwy Standardowa usługi Azure Service Bus. Przestrzeń nazw usługi Service Bus można uaktualnić z warstwy Standardowa do warstwy Premium, aby mieć wyższe limity przydziału i limity.

Zapisywanie utraconych komunikatów w scenariuszach automatycznego przesyłania dalej

Komunikaty są wysyłane do kolejki utraconych wiadomości w następujących warunkach:

• Komunikat przechodzi przez więcej niż cztery kolejki lub tematy, które są połączone w łańcuch.
• Kolejka docelowa lub temat jest wyłączona lub usuwana.
• Kolejka docelowa lub temat przekracza maksymalny rozmiar jednostki.

Wysyłanie utraconych komunikatów za pośrednictwem scenariuszy

• Jeśli kolejka docelowa lub temat jest wyłączona, komunikat jest wysyłany do kolejki utraconych komunikatów (TDLQ) kolejki źródłowej.
• Jeśli kolejka docelowa lub jednostka przekracza rozmiar jednostki, komunikat jest wysyłany do TDLQ kolejki źródłowej.

Wysyłanie utraconych komunikatów do ponownego przetworzenia

Po rozwiązaniu problemu, który spowodował, że komunikat został utracony, możesz ponownie przesłać go do kolejki lub tematu do ponownego przetworzenia.

Narzędzia takie jak Eksplorator usługi Azure Service Bus umożliwiają ręczne przenoszenie komunikatów między kolejkami i tematami. Jeśli istnieje wiele komunikatów w kolejce utraconych komunikatów, które muszą zostać przeniesione, kod podobny do tego może pomóc w przeniesieniu ich wszystkich naraz. Operatorzy często wolą mieć interfejs użytkownika, aby mogli rozwiązywać problemy z typami komunikatów, które nie powiodły się przetwarzanie, z jakich kolejek źródłowych i z jakich powodów nadal mogą ponownie przesyłać partie komunikatów do ponownego przetwarzania. Narzędzia, takie jak ServicePulse z NServiceBus , zapewniają te możliwości.

Powiązana zawartość

Zobacz Włączanie utraconych komunikatów dla kolejki lub subskrypcji , aby dowiedzieć się więcej o różnych sposobach konfigurowania utraconych komunikatów po wygaśnięciu wiadomości.