Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Pokud aplikace selže kvůli závažné chybě hned po odeslání zprávy a restartování instance aplikace se chybně domnívá, že předchozí doručení zprávy nedošlo, 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 o okamžik dříve k chybě a odeslaná zpráva se zařadí do fronty, avšak potvrzení se klientovi nepodaří úspěšně doručit. 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í některých kontextů 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é
- Když je povoleno dělení, používá se 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í) se používá pouze
MessageId, aby se určila jedinečnost. - Informace o
SessionIdnástroji ,PartitionKeyaMessageId, naleznete v tématu Použití klíčů oddílů. - Při použití partitionování a odesílání dávek zpráv byste měli zajistit, aby neobsahovaly žádné vlastnosti identifikující oddíl. Vzhledem k tomu, že deduplikace spoléhá na explicitní nastavení ID zpráv k určení jedinečnosti, nedoporučuje se používat deduplikaci a dávkování společně s dělením.
Poznámka:
Naplánované zprávy jsou zahrnuty do 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 rozpoznávání duplicit
Kromě povolení detekce 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 a maximální hodnotou 7 dnů.
Povolení detekce duplicit a velikost okna přímo ovlivňují propustnost fronty (a tématu), protože všechny zaznamenané identifikátory 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 klientské knihovny služby Azure Service Bus pro .NET (nejnovější)
- Ukázky klientské knihovny služby Azure Service Bus pro Javu (nejnovější)
- Ukázky klientské knihovny služby Azure Service Bus pro Python
- Ukázky klientské knihovny služby Azure Service Bus pro JavaScript
- Ukázky klientské knihovny služby Azure Service Bus pro TypeScript
Ukázky pro starší klientské knihovny .NET a Java najdete tady:
- Ukázky klientské knihovny služby Azure Service Bus pro .NET (starší verze)
- Ukázky klientské knihovny služby Azure Service Bus pro Javu (starší verze)
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.