Vyhledávání duplicit

  • Článek

Pokud aplikace selže kvůli závažné chybě hned po odeslání zprávy a restartovaná instance aplikace se chybně domnívá, že nedošlo k doručení předchozí zprávy, následné odeslání způsobí, že se stejná zpráva zobrazí v systému dvakrát.

Je také možné, že na úrovni klienta nebo sítě dojde k chybě na chvíli dříve a aby se odeslaná zpráva odeslala do fronty s potvrzením, že se klientovi nepodařilo úspěšně vrátit. Tento scénář ponechá klienta pochybností o výsledku operace odeslání.

Zjišťování duplicit vytáčí pochybnosti z těchto situací tím, že odesílateli umožní znovu odeslat stejnou zprávu a fronta nebo téma zahodí všechny duplicitní kopie.

Poznámka:

Úroveň Basic služby Service Bus nepodporuje detekci duplicit. Úrovně Standard a Premium detekci duplicit podporují. Rozdíly mezi těmito úrovněmi najdete v tématu Ceny služby Service Bus.

Jak to funguje

Povolení Detekce duplicitních dat pomáhá sledovat MessageId řízené aplikací u všech zpráv odeslaných do fronty nebo tématu během zadaného časového období. Pokud se během časového intervalu odešle MessageId nějaká nová zpráva, která byla zaprotokolována, zobrazí se zpráva jako akceptovaná (operace odeslání proběhne úspěšně), ale nově odeslaná zpráva se okamžitě ignoruje a zahodí. V úvahu se neberou žádné jiné části zprávy, než je MessageId.

Řízení aplikace identifikátoru je nezbytné, protože pouze to umožňuje aplikaci spojit MessageId s kontextem obchodního procesu, ze kterého může být předvídatelně rekonstruován, když dojde k selhání.

U obchodního procesu, ve kterém se v průběhu zpracování určitého kontextu aplikace odesílá více zpráv, MessageId může být složený z identifikátoru kontextu na úrovni aplikace, například čísla nákupní objednávky, a předmětu zprávy, například 12345.2017/payment.

Identifikátor MessageId guid může být vždy určitý, ale ukotvení identifikátoru k obchodnímu procesu přináší předvídatelnou opakovatelnost, což je žádoucí pro efektivní použití funkce detekce duplicit.

Důležité

  • Při povoleném MessageId+PartitionKeydělení se používá k určení jedinečnosti. Pokud jsou relace povolené, klíč oddílu a ID relace musí být stejné.
  • Při zakázání dělení (výchozí) slouží pouze MessageId k určení jedinečnosti.
  • Informace o SessionIdnástroji , PartitionKeya MessageId, naleznete v tématu Použití klíčů oddílů.

Poznámka:

Naplánované zprávy jsou součástí detekce duplicit. Proto pokud odešlete naplánovanou zprávu a pak odešlete duplicitní neplánovanou zprávu, dojde k vyřazení neplánované zprávy. Podobně platí, že pokud odešlete neplánovanou zprávu a potom duplicitní naplánovanou zprávu, naplánovaná zpráva se zahodí.

Velikost okna detekce duplicit

Kromě toho, že povolíte detekci duplicit, můžete také nakonfigurovat velikost časového intervalu historie duplicitních zjišťování, během kterého se zachovají ID zpráv. Výchozí hodnota je 10 minut pro fronty a témata s minimální hodnotou 20 sekund na maximální hodnotu 7 dnů.

Povolení detekce duplicit a velikost okna přímo ovlivňují propustnost fronty (a tématu), protože všechny zaznamenané ID zpráv se musí shodovat s nově odeslaným identifikátorem zprávy.

Zachování malého okna znamená, že musí být zachováno a spárováno méně ID zpráv a propustnost je ovlivněna méně. U entit s vysokou propustností, které vyžadují detekci duplicit, byste měli okno zachovat co nejmenší.

Další kroky

Detekci duplicitních zpráv můžete povolit pomocí webu Azure Portal, PowerShellu, rozhraní příkazového řádku, šablony Resource Manageru, .NET, Javy, Pythonu a JavaScriptu. Další informace najdete v tématu Povolení detekce duplicitních zpráv.

Ve scénářích, kdy klientský kód nemůže znovu odeslat zprávu se stejným ID zprávy jako předtím, je důležité navrhnout zprávy, které je možné bezpečně znovu zpracovat. Tento blogový příspěvek o idempotenci popisuje různé techniky, jak to udělat.

Vyzkoušejte ukázky v jazyce podle vašeho výběru a prozkoumejte funkce služby Azure Service Bus.

Ukázky pro starší klientské knihovny .NET a Java najdete tady:

30. září 2026 vyřadíme knihovny sady SDK služby Azure Service Bus pro WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus a com.microsoft.azure.servicebus, které nevyhovují pokynům sady Azure SDK. Také ukončíme podporu protokolu SBMP, takže tento protokol už nebudete moct používat po 30. září 2026. Před tímto datem migrujte na nejnovější knihovny sady Azure SDK, které nabízejí důležité aktualizace zabezpečení a vylepšené funkce.

I když starší knihovny je možné používat i po 30. září 2026, nebudou už od Microsoftu dostávat oficiální podporu a aktualizace. Další informace najdete v oznámení o vyřazení podpory.