Sdílet prostřednictvím

Relace zpráv

Relace služby Azure Service Bus umožňují společné a seřazené zpracování nevázaných sekvencí souvisejících zpráv. Relace je možné použít v prvním dovnitř, prvním ven (FIFO) a vzor požadavek-odpověď. 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 relace. Relace podpory úrovně Standard a Premium. Rozdíly mezi těmito úrovněmi najdete v tématu Ceny služby Service Bus.

První dovnitř, první ven (FIFO)

Pokud chcete dosáhnout zpracování FIFO při zpracování zpráv z front nebo odběrů 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čí.

Odesílatel může zahájit relaci při odesílání zpráv do tématu nebo fronty nastavením vlastnosti ID relace na jedinečný identifikátor definovaný aplikací. Na úrovni protokolu AMQP 1.0 se tato hodnota mapuje na vlastnost ID skupiny .

Ve frontách nebo předplatných citlivých na relace vzniknou relace, pokud existuje alespoň 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 za rok, a pokud se ID relace shoduje, relace je z pohledu služby Service Bus stejná.

Aplikace ale obvykle definuje, kde začíná a končí sada souvisejících zpráv. Service Bus neukládá žádná konkrétní pravidla. Aplikace může například nastavit vlastnost Popisek pro první zprávu jako začátek, pro přechodné zprávy jako obsah a poslední zprávu na konec. Relativní pozici obsahových zpráv lze vypočítat jako rozdíl aktuálního SequenceNumber zprávy 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. Klienti musí odesílat zprávy jako součást relace tím, že nastaví ID relace a přijmou relaci. 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 klientů předplatného. Existují dva způsoby, jak přijímat relace a zprávy: imperativní model, kde ručně řídíte, kdy a jak se zprávy přijímají, a model založený na obslužné rutině, který zjednodušuje věci automatickou správou smyčky a zpracování zpráv.

Pro ukázky použijte odkazy v části Ukázky .

Funkce relace

Relace poskytují souběžné demultiplexování prokládaných zprávových proudů při zachování a zaručení seřazeného doručení.

Diagram znázorňující, jak funkce Relací zachovává seřazenou dodávku.

Klient vytvoří přijímač relace, aby přijal relaci. Když klient přijme a uchovává relaci, klient má výhradní zámek na všechny zprávy s ID této relace ve frontě nebo odběru. Uchovává výhradní zámky u všech zpráv, které dorazí později, s ID relace.

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 prokládaný zprávový tok v jedné frontě nebo odběru čistě demultiplexován k různým příjemcům, a ti mohou také běžet na různých klientských počítačích, protože správa zámků probíhá na straně služby v rámci 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 nebo 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ý drží příjemce relace, zahrnuje zámky zpráv používané režimem vypořádání peek-lock. Pouze jeden příjemce může mít kontrolu nad relací. Příjemce může mít mnoho zpráv v letu, ale zprávy se přijímají v pořadí. Opustění zprávy způsobí, že stejná zpráva je znovu zpracována 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.

Funkce sledování stavu relace umožňuje aplikací definovanou anotaci relace zpráv uvnitř zprostředkovatele, aby zaznamenaný stav zpracování týkající se této relace byl okamžitě dostupný, když relaci převezme nový procesor.

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 pro správu stavu relace, SetState a GetState, lze nalézt v objektu příjemce relace. Relace, která dříve neměla žádný stav relace, vrací odkaz 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 (vrátí null), i když se zpracují všechny zprávy v relaci.

Stav relace uložený ve frontě nebo v předplatném se započítává do úložné kapacity 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ář Zvyšuje se počet doručení zprávy?
Relace se přijme, ale 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. Ne
Nejprve je relace přijata, poté jsou zprávy dokončeny, a nakonec se relace explicitně uzavře. Nedostupné (jedná se o standardní postup. 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 na frontu s povolenou relací, nastavujíc ID relace na jedinečný identifikátor, který odesílatel zaslal ve zprávě požadavku. Aplikace, která odeslala požadavek, bude moci přijímat zprávy s 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 znát ID relace a použít ho k přijetí relace, aby byla relace, od které očekává odpověď, uzamčená. Je vhodné použít identifikátor GUID, který jedineč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í versus relace

Pořadové číslo samo o sobě zaručuje řazení ve frontě a pořadí extrakce zpráv, ale ne pořadí zpracování, které vyžaduje session.

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

  1. Uživatel 1 vyzvedne zprávu 1.
  2. Spotřebitel 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 byly zprávy 1, 2 a 3 zpracovány v pořadí, 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 front nebo odběrů témat s aktivovaný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 označí jako mrtvé na základě povoleného označování zprávy jako mrtvé v rámci nastavení vypršení platnosti 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í posluchač. Další informace najdete v tématu Vypršení platnosti zprávy.

Vzorky

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.

Související obsah

  • Last updated on