Relace zpráv

  • Článek
  • 6 min ke čtení

Relace Service Bus Azure umožňují společné a seřazené zpracování sekvencí souvisejících zpráv bez vázané komunikace. Relace je možné používat ve vzorech FIFO (first in, first out) a request-response (odpověď na žádost). Tento článek popisuje, jak pomocí relací implementovat tyto vzory při použití Service Bus.

Poznámka

Základní úroveň Service Bus nepodporuje relace. Relace podporují úrovně Standard a Premium. Rozdíly mezi těmito úrovněmi najdete v tématu Service Bus ceny.

Model FIFO (First-In, First Out)

K realizaci záruky FIFO v Service Bus, použijte relace. Service Bus není normativní o povaze vztahu mezi zprávami a také nedefinuje konkrétní model pro určení, kde pořadí zpráv začíná 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 identifikátor definovaný aplikací, který je pro relaci jedinečný. Na úrovni protokolu AMQP 1.0 se tato hodnota mapuje na vlastnost group-id.

Ve frontách nebo předplatných s povědomím o relacích se relace chystá, 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 lze pro relaci dnes, další zprávu za rok přijata zpráva, a pokud se ID relace shoduje, relace je stejná z pohledu Service Bus prostředí.

Aplikace ale obvykle jasně cítí, kde začíná a končí sada souvisejících zpráv. Service Bus nenastaví žádná konkrétní pravidla. Vaše aplikace může například nastavit vlastnost Popisek u první zprávy tak, aby se s úvodní zprávou s úvodní zprávou sčítá , u zprostředkujících zpráv na obsah a u poslední zprávy až do konce. Relativní pozici zpráv obsahu lze vypočítat jako aktuální rozdíl sequenceNumber zprávy od počáteční zprávy SequenceNumber.

Důležité

Pokud jsou relace povolené ve frontě nebo odběru, klientské aplikace už nebudou moci odesílat a přijímat běžné zprávy. Všechny zprávy se musí odesílat jako součást relace (nastavením ID relace) a přijímat přijetím relace.

Rozhraní API pro relace existují v klientech fronty a předplatného. 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.

Pro ukázky použijte odkazy v části Další kroky.

Funkce relací

Relace zajišťují souběžné de multiplexování prokládaného datového proudu zpráv při zachování a zaručení seřazeného doručování.

Diagram znázorňující, jak funkce Relace zachovává seřazené doručování

Příjemce relace vytvoří klient, který přijímá relaci. Když je relace přijata a uchována klientem, klient má výhradní zámek pro všechny zprávy s ID relace této relace ve frontě nebo odběru. Bude také obsahovat výhradní zámky pro všechny zprávy s ID relace, které přijde později.

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

Když z fronty vytahuje více souběžných příjemců, zprávy patřící do konkrétní relace se odesílají konkrétnímu příjemci, který aktuálně obsahuje zámek pro tuto relaci. Díky této operaci se prokládané streamy zpráv v jedné frontě nebo odběru vyčistí do různých příjemců a tito příjemci mohou také živé na různých klientských počítačích, protože správa zámků probíhá na straně služby uvnitř Service Bus.

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

Zámek relace, který je uchován příjemcem relace, je zastřešující zastřešující zámky zpráv používané režimem peek-lock settlement. Zámek relace může mít pouze jeden příjemce. Příjemce může mít mnoho zpráv za letu, ale zprávy budou přijaty v pořadí. Opuštění zprávy způsobí, že se stejná zpráva bude znovu dostávat při další operaci přijetí.

Stav relace zprávy

Při zpracování pracovních postupů v cloudových systémech s vysokou dostupností musí být obslužná rutina pracovního postupu přidružená ke konkrétní relaci schopna 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ých byla práce zahájena.

Stavové zařízení relace umožňuje anotaci relace zpráv definované aplikací uvnitř zprostředkovatele, aby se zaznamenaný stav zpracování vzhledem k této relaci stal okamžitě dostupným po získání relace novým procesorem.

Z Service Bus pohledu 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í vzhledem k relaci se může uchovat ve stavu relace nebo stav relace může odkazovat na některé umístění úložiště nebo záznam databáze, který takové informace obsahuje.

Metody pro správu stavu relace SetState a GetState najdete v objektu příjemce relace. Relace, která dříve neměla žádný stav relace, vrací nulový odkaz pro GetState. Dříve nastavený stav relace je možné vymazat předáním hodnoty null metodě SetState na příjemci.

Stav relace zůstane, dokud není vyčištěný (vrací hodnotu null), i když se spotřebovávají všechny zprávy v relaci.

Stav relace, který se nachází ve frontě nebo v předplatném, se započítá do kvóty úložiště této entity. Po dokončení relace se proto doporučuje, aby aplikace vyčistěla zachované stavy, aby se zabránilo nákladům na externí správu.

Dopad počtu doručení

Definice počtu doručení na zprávu v kontextu relací se mírně liší od definice v případě absence relací. Tady je tabulka se souhrnem, kdy se zvýší počet doručení.

Scenario Zvýší se počet doručení zprávy?
Relace je přijata, ale platnost zámku relace vyprší (kvůli vypršení časového limitu). Yes
Relace je přijata, zprávy v rámci relace se neskončí (i když jsou uzamčené) a relace se zavře. No
Relace je přijata, zprávy se dokončí a pak se relace explicitně zavře. Není k dispozici (jedná se o standardní tok. Zde jsou zprávy odebrány z relace.)

Vzor požadavku a odpovědi

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

Několik aplikací může odesílat své požadavky do jedné fronty požadavků s konkrétním parametrem hlavičky nastaveným na jednoznačnou identifikaci aplikace odesílatele. Přijímací aplikace může zpracovat požadavky přicházející do fronty a odesílat odpovědi do fronty s povolenou relací a nastavit ID relace na jedinečný identifikátor, který odesílatel odeslal ve zprávě žádosti. Aplikace, která odeslala požadavek, pak může přijímat zprávy o 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 ji k přijetí relace, aby relace, ve které očekává, že odpověď byla uzamčena. Je vhodné použít identifikátor GUID, který jednoznačně identifikuje instanci aplikace jako ID relace. U příjemce relace by neměla být zadána žádná obslužná rutina relace ani časový limit, aby fronta měla k dispozici odpovědi, které příjemci uzamknou a zpracují.

Další kroky

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

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

Ukázky pro starší klientské knihovny .NET a Javy najdete níže: