Sdílet prostřednictvím

Relace zpráv

  • Článek

Relace služby Azure Service Bus umožňují společné a seřazené zpracování sekvencí souvisejících zpráv bez vazby. Relace je možné použít jako první v, nejprve ven (FIFO) a vzory odezvy požadavků . Tento článek ukazuje, jak používat relace k implementaci těchto vzorů při použití služby Service Bus.

Poznámka:

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

První in, první vzorek (FIFO)

K realizaci záruky FIFO při zpracování zpráv ve frontách nebo odběrech služby Service Bus použijte relace. Service Bus není prescriptivní o povaze vztahu mezi zprávami a také nedefinuje konkrétní model pro určení, kde se sekvence zpráv spouští nebo končí.

Každý odesílatel může vytvořit relaci při odesílání zpráv do tématu nebo fronty nastavením vlastnosti ID relace na určitý identifikátor definovaný aplikací, který je pro relaci jedinečný. Na úrovni protokolu AMQP 1.0 se tato hodnota mapuje na vlastnost ID skupiny.

V frontách nebo předplatných pracujících s relacemi se relace objeví, pokud existuje aspoň jedna zpráva s ID relace. Jakmile relace existuje, neexistuje žádný definovaný čas ani rozhraní API, kdy relace vyprší nebo zmizí. Teoreticky může být zpráva přijata pro relaci dnes, další zpráva v ročním čase a pokud se ID relace shoduje, relace je stejná z pohledu služby Service Bus.

Aplikace ale obvykle má jasnou představu o tom, kde začíná a končí sada souvisejících zpráv. Service Bus nenastavuje žádná konkrétní pravidla. Aplikace může například nastavit vlastnost Popisek pro první zprávu, zprostředkující zprávy do obsahu a poslední zprávu ukončit. Relativní pozici zpráv obsahu lze vypočítat jako aktuální pořadové číslo zprávy delta od počáteční zprávy SequenceNumber.

Důležité

Pokud jsou relace povoleny ve frontě nebo předplatném, klientské aplikace už nemůžou odesílat a přijímat běžné zprávy. Všechny zprávy musí být odeslány jako součást relace (nastavením ID relace) a přijaté přijetím relace. Klienti si stále můžou prohlédnout frontu nebo předplatné, které má povolené relace. Viz Procházení zpráv.

Rozhraní API pro relace existují u klientů front a předplatných. Existuje imperativní model, který řídí, kdy se přijímají relace a zprávy, a model založený na obslužné rutině, který skrývá složitost správy smyčky příjmu.

V případě ukázek použijte odkazy v části Další kroky .

Funkce relace

Relace poskytují souběžné demultiplexní prokládání datových proudů zpráv při zachování a záruku seřazeného doručení.

Diagram that shows how the Sessions feature preserves an ordered delivery.

Příjemce relace se vytváří klientem, a to přijetím relace. Když je relace přijata a držena klientem, klient uchovává výhradní zámek pro všechny zprávy s ID relace této relace ve frontě nebo odběru. Uchovává výhradní zámky u všech zpráv s ID relace, které se dorazí později.

Zámek se uvolní při volání metod zavření na přijímači nebo při vypršení platnosti zámku. Na přijímači jsou také metody obnovení zámků. Místo toho můžete použít funkci automatického prodlužování zámku, kde můžete zadat dobu trvání, po kterou chcete zámek obnovit. Zámek relace by se měl považovat za výhradní zámek souboru, což znamená, že aplikace by relaci měla zavřít, jakmile ji už nepotřebuje nebo neočekává žádné další zprávy.

Když se z fronty stáhne více souběžných příjemců, zprávy patřící do konkrétní relace se odešlou konkrétnímu příjemci, který aktuálně vlastní zámek pro danou relaci. Při této operaci je stream prokládání zpráv v jedné frontě nebo odběru čistě demultiplexován různým příjemcům a tito příjemci mohou také žít na různých klientských počítačích, protože správa zámků probíhá na straně služby uvnitř služby Service Bus.

Předchozí obrázek znázorňuje tři souběžné přijímače relace. Jedna relace s SessionId = 4 nemá aktivního klienta, vlastnícího klienta, což znamená, že z této konkrétní relace nejsou doručeny žádné zprávy. Relace funguje mnoha způsoby jako dílčí fronta.

Zámek relace, který je uložený příjemcem relace, je deštníkem pro zámky zpráv používané režimem vypořádání náhledu zámku . Zámek relace může mít jenom jeden příjemce. Příjemce může mít mnoho zpráv v letu, ale zprávy se přijímají v pořadí. Opuštění zprávy způsobí, že se stejná zpráva bude znovu obsluhovat při další operaci příjmu.

Stav relace zprávy

Při zpracování pracovních postupů ve vysoce škálovatelných cloudových systémech s vysokou dostupností musí být obslužná rutina pracovního postupu přidružená k určité relaci schopná zotavit se z neočekávaných selhání a může obnovit částečně dokončenou práci na jiném procesu nebo počítači, ze kterého byla práce zahájena.

Zařízení stavu relace umožňuje aplikaci definovanou anotaci relace zprávy uvnitř zprostředkovatele, aby byl zaznamenaný stav zpracování relativní k této relaci okamžitě dostupný, když je relace získána novým procesorem.

Z pohledu služby Service Bus je stav relace zprávy neprůhledný binární objekt, který může obsahovat data o velikosti jedné zprávy, což je 256 kB pro Service Bus Standard a 100 MB pro Service Bus Premium. Stav zpracování relativní k relaci může být uložen uvnitř stavu relace, nebo stav relace může odkazovat na některé umístění úložiště nebo záznam databáze, který tyto informace obsahuje.

Metody správy stavu SetState relace a GetState, lze nalézt v objektu příjemce relace. Relace, která dříve neměla žádný stav relace, nevrací odkaz na hodnotu null pro GetState. Dříve nastavený stav relace lze vymazat předáním hodnoty null SetState metodě příjemce.

Stav relace zůstane tak dlouho, dokud se nevymaže (vrací hodnotu null), i když se spotřebují všechny zprávy v relaci.

Stav relace uložený ve frontě nebo v předplatném se počítá do kvóty úložiště dané entity. Po dokončení relace se proto doporučuje, aby aplikace vyčistila svůj zachováný stav, aby se zabránilo externím nákladům na správu.

Dopad počtu doručení

Definice počtu doručení na zprávu v kontextu relací se mírně liší od definice bez relací. Tady je tabulka, která shrnuje, kdy se zvýší počet doručení.

Scénář Zvýší se počet doručení zprávy.
Relace se přijme, ale platnost uzamčení relace vyprší (kvůli vypršení časového limitu). Ano
Relace se přijme, zprávy v rámci relace se nedokončí (i když jsou uzamčené) a relace se zavře. No
Relace se přijme, zprávy se dokončí a relace se explicitně zavře. Není k dispozici (jedná se o standardní tok. Tady se zprávy odeberou z relace.

Model odpovědi na požadavek

Model odpovědi na požadavek je dobře zavedený model integrace, který aplikaci odesílatele umožňuje odeslat požadavek a poskytuje příjemci způsob, jak správně odeslat odpověď zpět do aplikace odesílatele. Tento model obvykle potřebuje krátkodobou frontu nebo téma, do které aplikace odesílá odpovědi. V tomto scénáři relace poskytují jednoduché alternativní řešení se srovnatelnou sémantikou.

Více aplikací může odesílat své požadavky do jedné fronty požadavků s konkrétním parametrem hlavičky nastaveným na jedinečnou identifikaci aplikace odesílatele. Aplikace příjemce může zpracovávat žádosti přicházející do fronty a odesílat odpovědi ve frontě s povolenou relací a nastavit ID relace na jedinečný identifikátor, který odesílatel odeslal ve zprávě požadavku. Aplikace, která odeslala požadavek, pak může přijímat zprávy na konkrétním ID relace a správně zpracovávat odpovědi.

Poznámka:

Aplikace, která odesílá počáteční požadavky, by měla vědět o ID relace a použít ji k přijetí relace, aby relace, na které očekává, že odpověď je uzamčena. Je vhodné použít identifikátor GUID, který jednoznačně identifikuje instanci aplikace jako ID relace. Pro frontu by neměla existovat žádná obslužná rutina relace ani časový limit určený pro příjemce relace, aby se zajistilo, že odpovědi budou k dispozici pro uzamčení a zpracování konkrétními příjemci.

Sekvencování a relace

Pořadové číslo na vlastní straně zaručuje pořadí front a pořadí extrakce zpráv, ale ne pořadí zpracování, které vyžaduje relace.

Řekněme, že ve frontě jsou tři zprávy a dva příjemci.

  1. Uživatel 1 vyzvedne zprávu 1.
  2. Uživatel 2 přebírá zprávu 2.
  3. Uživatel 2 dokončí zpracování zprávy 2 a vybere zprávu 3, zatímco uživatel 1 ještě se zprávou zpracování 1 není hotový.
  4. Příjemce 2 dokončí zpracování zprávy 3, ale příjemce 1 ještě není dokončen se zpracováním zprávy 1.
  5. Příjemce 1 nakonec dokončí zpracování zprávy 1.

Zprávy se tedy zpracovávají v tomto pořadí: zpráva 2, zpráva 3 a zpráva 1. Pokud potřebujete, aby se zpracovávala zpráva 1, 2 a 3, musíte použít relace.

Pokud zprávy stačí načíst v pořadí, nemusíte používat relace. Pokud je potřeba zpracovat zprávy v pořadí, použijte relace. Stejné ID relace by se mělo nastavit u zpráv, které patří dohromady, což může být zpráva 1, 4 a 8 v sadě a 2, 3 a 6 v jiné sadě.

Vypršení platnosti zprávy

U odběrů front nebo témat s povolenými relacemi se zprávy zamknou na úrovni relace. Pokud vyprší platnost hodnoty TTL (time-to-live) pro některou ze zpráv, všechny zprávy související s danou relací se buď zahodí, nebo nedoručené dopisy na základě povoleného nedoručených zpráv v nastavení vypršení platnosti zasílání zpráv u entity. Jinými slovy, pokud v relaci existuje jedna zpráva, která předala hodnotu TTL, platnost všech zpráv v relaci vypršela. Platnost zpráv vyprší jenom v případě, že je aktivní naslouchací proces. Další informace najdete v tématu Vypršení platnosti zprávy.

Další kroky

Relace zpráv můžete povolit při vytváření fronty pomocí webu Azure Portal, PowerShellu, rozhraní příkazového řádku, šablony Resource Manageru, .NET, Javy, Pythonu a JavaScriptu. Další informace naleznete v tématu Povolení relací zpráv.

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