Fronty, témata a odběry služby Service Bus

  • Článek

Azure Service Bus podporuje spolehlivé řazení zpráv do front a trvalé publikování a zasílání zpráv k odběru. Entity zasílání zpráv, které tvoří jádro funkcí zasílání zpráv ve službě Service Bus, jsou fronty, témata a odběry.

Důležité

Pokud se službou Azure Service Bus teprve začínáte, přečtěte si , co je Azure Service Bus? Než se pustíte do tohoto článku.

Fronty

Fronty nabízejí doručování zpráv metodou FIFO (First In First Out) pro jednoho nebo několik konkurenčních spotřebitelů. To znamená, že příjemci obvykle přijímají a zpracovávají zprávy v pořadí, v jakém byly přidány do fronty. A každá zpráva přijímá a zpracovává pouze jeden příjemce zpráv.

Obrázek znázorňující, jak fungují fronty služeb

Klíčovou výhodou používání front je dosažení dočasného oddělení komponent aplikace. Jinými slovy, producenti (odesílatelé) a příjemci (příjemci) nemusí posílat a přijímat zprávy současně, protože zprávy jsou uloženy trvale ve frontě. Producent navíc nemusí čekat na odpověď od příjemce, aby dál zpracovával a odesílal zprávy.

Související výhodou je vyrovnávání zatížení, které umožňuje výrobcům a příjemcům posílat a přijímat zprávy různými rychlostmi. V mnoha aplikacích se zatížení systému v průběhu času liší. Doba zpracování potřebná pro každou jednotku práce je však obvykle konstantní. Meziprostředkující producenti zpráv a příjemci s frontou znamená, že spotřebová aplikace musí být schopná zpracovávat průměrné zatížení místo zatížení ve špičce. S měnící se příchozí zátěží se mění hloubka fronty. Tato funkce přímo šetří peníze týkající se množství infrastruktury potřebné k poskytování služby zatížení aplikace. S rostoucím zatížením je možné přidat více pracovních procesů ke čtení z fronty. Každou zprávu zpracovává jen jeden pracovní proces. Toto vyrovnávání zatížení založené na vyžádání navíc umožňuje nejlepší využití pracovních počítačů i v případě, že pracovní počítače se zpracováním zpráv o výkonu získávají vlastní maximální rychlost. Tomuto chování se často říká konkurence mezi spotřebiteli.

Použití front k zprostředkování mezi producenty zpráv a příjemci poskytuje základní volné spojení mezi komponentami. Vzhledem k tomu, že producenti a spotřebitelé si navzájem neuvědomují, může být spotřebitel upgradován , aniž by to mělo na producenta žádný vliv.

Vytvoření front

Fronty můžete vytvářet pomocí jedné z následujících možností:

Pak můžete odesílat a přijímat zprávy pomocí klientů napsaných v programovacích jazycích, včetně následujících:

Režimy příjmu

Můžete zadat dva různé režimy, ve kterých příjemci mohou přijímat zprávy ze služby Service Bus.

  • Přijmout a odstranit. Když Service Bus v tomto režimu obdrží požadavek od příjemce, označí zprávu jako spotřebovanou a vrátí ji do aplikace příjemce. Tento režim je nejjednodušším modelem. Nejlépe funguje ve scénářích, ve kterých může aplikace tolerovat, že v případě selhání zprávu nezpracovala. Abyste pochopili tento scénář, zvažte scénář, ve kterém příjemce vydá žádost o přijetí, a pak se před zpracováním chybově ukončí. Protože Service Bus označí zprávu jako spotřebovanou, aplikace začne po restartování přijímat zprávy. Zmešká se zpráva, kterou spotřebovala před chybou. Tento proces se často nazývá zpracování najednou.
  • Nahlédněte do zámku. V tomto režimu je operace přijetí dvoufázový proces, díky němuž lze podporovat aplikace, které nemohou tolerovat chybějící zprávy.

    1. Najde další zprávu, která se má spotřebovat, uzamkne ji, aby ji ostatní příjemci nemohli přijmout, a pak zprávu vrátí do aplikace.

    2. Jakmile aplikace dokončí zpracování zprávy, požádá službu Service Bus o dokončení druhé fáze procesu příjmu. Služba pak označí zprávu jako spotřebovanou.

      Pokud aplikace nemůže zprávu z nějakého důvodu zpracovat, může požádat službu Service Bus o opuštění zprávy. Service Bus zprávu odemkne a zpřístupní ji znovu, buď stejným příjemcem, nebo jiným konkurenčním příjemcem. Za druhé je časový limit spojený se zámkem. Pokud aplikace nedokáže zprávu zpracovat před vypršením zámku, služba Service Bus ji odemkne a zpřístupní ji pro opětovné přijetí.

      V případě, že se aplikace po zpracování zprávy chybově ukončí, ale ještě před tím požádá službu Service Bus o její dokončení, služba zprávu při restartování znovu odešle do aplikace. Tento proces se často nazývá alespoň jednou zpracování. To znamená, že každá zpráva se zpracuje alespoň jednou. V některých situacích ale může být stejná zpráva znovu převedena. Pokud váš scénář nedokáže tolerovat duplicitní zpracování, přidejte do aplikace další logiku, která detekuje duplicity. Další informace najdete v tématu Detekce duplicit, která se označuje jako přesně jednou zpracování.

      Poznámka:

      Další informace otěchtoch

Témata a předplatná

Fronta umožňuje zpracování zprávy jedním příjemcem. Na rozdíl od front poskytují témata a odběry formu komunikace 1:N ve vzoru publikování a odběru. To je užitečné pro škálování na velký počet příjemců. Každá publikovaná zpráva je k dispozici každému odběru zaregistrovanému v tématu. Publisher odešle zprávu do tématu a jeden nebo více odběratelů obdrží kopii zprávy.

Obrázek znázorňující téma služby Service Bus se třemi předplatnými

Předplatná můžou používat více filtrů k omezení zpráv, které chtějí přijímat. Vydavatelé odesílají zprávy do tématu stejným způsobem jako zprávy do fronty. Příjemci ale nedostávají zprávy přímo z tématu. Místo toho příjemci přijímají zprávy z odběrů tématu. Odběr tématu se podobá virtuální frontě, která přijímá kopie zpráv odesílaných do tématu. Příjemci dostanou zprávy z odběru stejně jako zprávy z fronty.

Funkce odesílání zpráv fronty se mapuje přímo na téma a její funkce příjmu zpráv se mapuje na odběr. Mimo jiné tato funkce znamená, že předplatná podporují stejné vzory popsané dříve v této části týkající se front: konkurenčního příjemce, dočasného oddělení, vyrovnávání zatížení a vyrovnávání zatížení.

Vytvoření témat a odběrů

Vytvoření tématu se podobá vytvoření fronty, jak je popsáno v předchozí části. Témata a odběry můžete vytvářet pomocí jedné z následujících možností:

Pak můžete odesílat zprávy do tématu a přijímat zprávy z odběrů pomocí klientů napsaných v programovacích jazycích, včetně následujících:

Pravidla a akce

V mnoha scénářích musí být zprávy, které mají specifické charakteristiky, zpracovány různými způsoby. Chcete-li povolit toto zpracování, můžete nakonfigurovat odběry tak, aby našly zprávy s požadovanými vlastnostmi a pak provedly určité úpravy těchto vlastností. I když odběry služby Service Bus uvidí všechny zprávy odeslané do tématu, je možné zkopírovat pouze podmnožinu těchto zpráv do fronty virtuálního předplatného. Toto filtrování se provádí pomocí filtrů předplatného. Takové úpravy se nazývají akce filtru. Po vytvoření odběru můžete zadat výraz filtru, který pracuje s vlastnostmi zprávy. Vlastnosti mohou být systémové vlastnosti (například Popisek) i vlastní vlastnosti aplikace (například StoreName).) Výraz filtru SQL je v tomto případě volitelný. Bez výrazu filtru SQL se všechny akce filtru definované v předplatném provádějí na všech zprávách pro toto předplatné.

Úplný příklad práce najdete v ukázce TopicFilters na GitHubu. Další informace o filtrech najdete v tématu Filtry a akce.

Entity služby zpráv Java (JMS) 2.0

Následující entity jsou přístupné prostřednictvím rozhraní API JMS (Java Message Service) 2.0.

  • Dočasné fronty
  • Dočasná témata
  • Sdílená odolná předplatná
  • Zrušení sdílení trvalých předplatných
  • Sdílená non-durable předplatná
  • Nesdílené non-durable předplatná

Přečtěte si další informace o entitách JMS 2.0 a o tom , jak je používat.

Expresní entity

Pro scénáře s vysokou propustností a nižší latencí se vytvořily expresní entity. Pokud se u expresních entit odešle zpráva do fronty nebo tématu, není okamžitě uložena v úložišti zpráv. Místo toho se zpráva zpočátku ukládá do mezipaměti. Zprávy, které zůstávají v entitě, se zapisují do úložiště zpráv po zpoždění, v jakém okamžiku jsou chráněny před ztrátou kvůli výpadku.

V běžných entitách se všechny operace za běhu (například Send, Complete, Abandon, Deadletter) zachovají jako první do úložiště a teprve potom, co se potvrdí klientovi jako úspěšné. V expresních entitách se jako první potvrdí operace modulu runtime klientovi jako úspěšná a teprve později líná do úložiště. V důsledku toho se v případě restartování počítače nebo v případě problému s hardwarem nemusí některé potvrzené operace modulu runtime vůbec zachovat. To znamená, že klient získá nižší latenci a vyšší propustnost s expresními entitami, a to na úkor potenciální ztráty dat nebo opětovného nasazení zpráv.

V rámci služby Service Bus se navíc v průběhu času provedlo mnoho optimalizací, což znamená, že výhody propustnosti a latence expresních entit jsou v současné době minimální. Kromě toho úroveň Premium služby Service Bus nepodporuje entity Express. Z tohoto důvodu se v současné době nedoporučuje používat tuto funkci.

Další kroky

Vyzkoušejte ukázky v jazyce podle vašeho výběru:

Ukázky, které používají starší klientské knihovny .NET a Java, použijte následující odkazy:

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.