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, z pomocą operatora, rozwiązać problemy i ponownie przesłać komunikat, zarejestrować fakt, że wystąpił błąd, i podjąć działania naprawcze.
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 dostarczanie zaglądania blokady i 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.
Liczba komunikatów DLQ
Nie można uzyskać liczby komunikatów w kolejce utraconych komunikatów na poziomie tematu. Dzieje się tak, 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.
| Przyczyna śmierci | Opis błędu utraconych komunikatów |
|---|---|
HeaderSizeExceeded |
Przekroczono limit przydziału rozmiaru dla tego strumienia. |
TTLExpiredException |
Komunikat wygasł i został uznany za utracony. Aby uzyskać szczegółowe informacje, zobacz sekcję Czas wygaśnięcia . |
| Identyfikator sesji ma wartość null. | Jednostka z obsługą sesji nie pozwala na komunikat, którego identyfikator sesji ma wartość null. |
MaxTransferHopCountExceeded |
Maksymalna liczba dozwolonych przeskoków podczas przekazywania między kolejkami została przekroczona. Ta wartość jest ustawiona na 4. |
MaxDeliveryCountExceeded |
Nie można użyć komunikatu po maksymalnych próbach dostarczenia. Aby uzyskać szczegółowe informacje, zobacz sekcję Maksymalna liczba dostaw. |
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 został dostarczony w ramach zaglądania blokady, ale został 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ę.
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. To zachowanie jest celowe.
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 nie wszystkie typy komunikatów mają subskrybentów.
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.
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, co dodatkowo wskazuje, że warstwa Premium powinna być używana w środowiskach produkcyjnych.
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 temat zostanie usunięty, zostanie zgłoszony wyjątek 404.
- Jeśli kolejka docelowa lub jednostka przekracza rozmiar jednostki, komunikat jest wysyłany do TDLQ kolejki źródłowej.
Ś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
Wysyłanie utraconych komunikatów do ponownego przetworzenia
Ponieważ mogą istnieć cenne dane biznesowe w komunikatach, które zakończyły się w kolejce utraconych komunikatów, pożądane jest ponowne przetwarzanie tych komunikatów, gdy operatory zakończyły pracę z okolicznościami, które spowodowały, że komunikaty zostały utracone w pierwszej kolejności.
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 zakończyły się niepowodzeniem przetwarzania, 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.
Następne kroki
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.