Wykrywanie duplikatów w Azure Service Bus

Jeśli działanie aplikacji zakończy się niepowodzeniem z powodu błędu krytycznego natychmiast po wysłaniu komunikatu, a ponownie uruchomiona instancja aplikacji błędnie uzna, że wcześniejszy komunikat nie został dostarczony, kolejna próba wysłania spowoduje, że ten sam komunikat pojawi się w systemie dwukrotnie.

Istnieje również możliwość wystąpienia błędu na poziomie klienta lub sieci chwilę wcześniej, a wysłany komunikat został zatwierdzony do kolejki, a potwierdzenie nie zostało pomyślnie zwrócone do klienta. Ten scenariusz pozostawia klientowi wątpliwości co do wyniku operacji wysyłania.

Wykrywanie duplikatów eliminuje wątpliwości co do tych sytuacji, umożliwiając nadawcy ponowne wysłanie tego samego komunikatu, a kolejka lub temat odrzuca wszelkie zduplikowane kopie.

Jak to działa

Uwaga

Warstwa podstawowa usługi Service Bus nie obsługuje wykrywania duplikatów. Wykrywanie duplikatów obsługują warstwy Standardowa i Premium. Aby poznać różnice między tymi warstwami, zobacz Cennik usługi Service Bus.

Włączenie funkcji wykrywania duplikatów ułatwia śledzenie kontrolowanej przez aplikację właściwości wszystkich komunikatów wysyłanych do kolejki lub tematu w określonym przedziale czasu. Jeśli zostanie wysłana jakakolwiek nowa wiadomość z MessageId, która została zarejestrowana w przedziale czasu, Service Bus zgłasza komunikat jako zaakceptowany (operacja wysyłania zakończy się powodzeniem), ale nowo wysłana wiadomość zostanie natychmiast zignorowana i porzucona. Żadne inne części komunikatu poza MessageId nie są brane pod uwagę.

Kontrola aplikacji nad identyfikatorem jest niezbędna, ponieważ umożliwia aplikacji powiązanie MessageId elementu z kontekstem procesu biznesowego, z którego można go przewidzieć, gdy wystąpi awaria.

W przypadku procesu biznesowego, w którym wiele komunikatów jest wysyłanych w trakcie obsługi kontekstu aplikacji, MessageId może to być złożony identyfikator kontekstu na poziomie aplikacji, taki jak numer zamówienia zakupu i temat komunikatu, na przykład 12345.2017/płatność.

MessageId zawsze może mieć postać identyfikatora GUID, ale powiązanie identyfikatora z procesem biznesowym zapewnia przewidywalną powtarzalność, co ma istotne znaczenie dla skutecznego korzystania z funkcji wykrywania duplikatów.

Ważne

  • Gdy partycjonowanie jest włączone, MessageId+PartitionKey służy do określania unikatowości. Po włączeniu sesji klucz partycji i identyfikator sesji muszą być takie same.
  • Gdy partycjonowanie jest wyłączone (ustawienie domyślne), służy tylko MessageId do określania unikatowości.
  • Aby uzyskać informacje o SessionId, PartitionKey i MessageId, zobacz Używanie kluczy partycji.
  • W przypadku używania partycjonowania i wysyłania partii komunikatów upewnij się, że nie zawierają żadnych właściwości identyfikujących partycje. Ponieważ deduplikacja polega na jawnym ustawianiu identyfikatorów komunikatów w celu określenia unikatowości, nie zaleca się używania deduplikacji i dzielenia na partie razem z partycjonowaniem.

Uwaga

Zaplanowane komunikaty są uwzględniane w wykrywaniu duplikatów. Dlatego, jeśli wyślesz zaplanowaną wiadomość, a następnie wyślesz zduplikowaną, nieplanowaną wiadomość, to ta nieplanowana wiadomość zostanie odrzucona. Podobnie, jeśli wyślesz nieplanowany komunikat, a następnie zduplikowany zaplanowany komunikat, zaplanowany komunikat zostanie porzucony.

Rozmiar okna wykrywania duplikatów

Oprócz włączenia wykrywania duplikatów można również skonfigurować rozmiar przedziału czasu historii wykrywania duplikatów, w którym są zachowywane identyfikatory komunikatów. Ta wartość domyślna to 10 minut dla kolejek i tematów z minimalną wartością 20 sekund i maksymalną wartością 7 dni.

Włączenie wykrywania duplikatów i rozmiar okna bezpośrednio wpływa na przepływność kolejki (i tematu), ponieważ wszystkie zarejestrowane identyfikatory komunikatów muszą być dopasowane do nowo przesłanego identyfikatora komunikatu.

Utrzymanie małego okna oznacza, że mniej identyfikatorów komunikatów musi być zachowywanych i dopasowywanych, co powoduje mniejsze oddziaływanie na przepustowość. W przypadku jednostek o wysokiej przepływności, które wymagają wykrywania duplikatów, zachowaj możliwie najmniejsze okno.

Następne kroki

Wykrywanie zduplikowanych komunikatów można włączyć przy użyciu portalu Azure, programu PowerShell, interfejsu wiersza polecenia, szablonu Resource Manager, .NET, Java, Python i języka JavaScript. Aby uzyskać więcej informacji, zobacz Włączanie wykrywania zduplikowanych komunikatów.

W scenariuszach, w których kod klienta nie może ponownie przesłać komunikatu o tym samym identyfikatorze MessageId co poprzednio, projektuj komunikaty, które można bezpiecznie ponownie przetworzyć. W tym wpisie w blogu dotyczącym idempotencji opisano różne techniki dotyczące tego, jak to zrobić.

Wypróbuj przykłady w wybranym języku, aby zapoznać się z funkcjami usługi Azure Service Bus.

Zobacz przykłady starszych bibliotek klienckich .NET i Java tutaj:

30 września 2026 r. wycofamy biblioteki zestawu SDK usługi Azure Service Bus WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus i com.microsoft.azure.servicebus, które nie są zgodne z wytycznymi dotyczącymi zestawu Azure SDK. Zakończymy również obsługę protokołu SBMP, więc nie będzie można już używać tego protokołu po 30 września 2026 r. Przeprowadź migrację do najnowszych bibliotek zestawu Azure SDK, które oferują krytyczne aktualizacje zabezpieczeń i ulepszone możliwości przed tą datą.

Mimo że starsze biblioteki mogą być nadal używane poza 30 września 2026 r., nie będą już otrzymywać oficjalnej pomocy technicznej i aktualizacji od firmy Microsoft. Aby uzyskać więcej informacji, zobacz ogłoszenie o wycofaniu pomocy technicznej.

  • Last updated on