Udostępnij za pośrednictwem

Wykrywanie duplikatów

  • Artykuł

Jeśli aplikacja nie powiedzie się z powodu błędu krytycznego natychmiast po wysłaniu komunikatu, a uruchomione ponownie wystąpienie aplikacji błędnie uważa, że poprzednie dostarczanie komunikatów nie wystąpiło, kolejne wysyłanie powoduje, że ten sam komunikat pojawia się w systemie dwa razy.

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

Wykrywanie duplikatów eliminuje wątpliwości dotyczące tych sytuacji, włączając nadawcę ponownie wyślij ten sam komunikat, a kolejka lub temat odrzuca wszelkie zduplikowane kopie.

Uwaga

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

Jak to działa

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 w oknie czasowym zostanie wysłana MessageId jakakolwiek nowa wiadomość, komunikat zostanie zgłoszony 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 identyfikatorem 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ść.

Zawsze MessageId może to być identyfikator GUID, ale zakotwiczenie identyfikatora w procesie biznesowym daje przewidywalną powtarzalność, która jest wymagana do efektywnego używania 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 SessionIdsystemach , PartitionKeyi MessageId, zobacz Use of partition keys (Używanie kluczy partycji).
  • W przypadku używania partycjonowania i wysyłania partii komunikatów należy upewnić 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 wraz z partycjonowaniem.

Uwaga

Zaplanowane komunikaty są uwzględniane w wykrywaniu duplikatów. W związku z tym, jeśli wyślesz zaplanowany komunikat, a następnie wyślesz zduplikowany, nieplanowany komunikat zostanie porzucony. 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łączania wykrywania duplikatów można również skonfigurować rozmiar przedziału czasu historii wykrywania duplikatów, podczas którego są zachowywane identyfikatory komunikatów. Ta wartość domyślna to 10 minut dla kolejek i tematów z minimalną wartością 20 sekund do maksymalnej wartości wynoszącej 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 dopasowanych, a przepływność ma mniejszy wpływ. W przypadku jednostek o wysokiej przepływności, które wymagają wykrywania duplikatów, należy zachować możliwie najmniejsze okno.

Następne kroki

Wykrywanie zduplikowanych komunikatów można włączyć przy użyciu witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia, szablonu usługi Resource Manager, platformy .NET, języka Java, języka 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 wcześniej, ważne jest zaprojektowanie komunikatów, 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.