AMQP (Advanced Message Queuing Protocol) je otevřený protokol aplikační vrstvy pro předávání zpráv mezi systémovými komponentami. Hlavní myšlenkou je, že jednotlivé subsystémy (nebo nezávislé aplikace) si mohou libovolně vyměňovat zprávy prostřednictvím AMQP brokera, který provádí směrování , případně garantuje doručení, distribuci datových toků, přihlášení k požadovaným typům zpráv.
Architekturu protokolu vyvinul John O'Hara z JP Morgan Chase & Co [1] .
AMQP je založen na třech konceptech:
Protokol lze rozdělit do dvou vrstev:
Příklady fronty:
Protokol není omezen na tyto tři druhy. Jsou uvedeny jako příklad implementace.
Přijímá zprávy od poskytovatele a směruje je do fronty zpráv podle předem definovaných kritérií. Taková kritéria se nazývají vazby. Exchange je mechanismus vyjednávání a směrování zpráv. Na základě zpráv a jejich parametrů (vazeb) rozhodnou o přesměrování na frontu nebo jinou ústřednu. Neukládejte zprávy.
Termín výměna znamená algoritmus a instance algoritmu. Říkají také typ výměny a instance výměny.
AMQP definuje sadu standardních typů výměn. Aplikace si mohou vytvořit vlastní instanci výměny.
Každá burza implementuje svůj vlastní směrovací algoritmus. Existuje několik standardních typů výměn popsaných ve funkční specifikaci normy. Z nich jsou důležité dva:
Server vytvoří několik výměn, včetně přímých a tematických. Budou mít známá jména a klientské aplikace s nimi budou umět pracovat.
Každý server AMQP předem vytváří několik instancí výměny. Tyto instance existují, když je server spuštěn a nelze je zničit. Aplikace AMQP mohou také vytvářet své vlastní burzy. AMQP k tomu nepoužívá metodu create, místo toho je deklarována instance, která se řídí logikou: „vytvořit, pokud není vytvořen, pokračovat jinak“. Dá se říci, že vytváření směny je idempotentní . Aplikace pravděpodobně vytvoří výměny podle potřeby a poté je zničí jako zbytečné. AMQP poskytuje metodu pro zničení výměny.
Obecně platí, že ústředna zkoumá vlastnosti zprávy, pole záhlaví a obsah jejího těla a pomocí těchto a případně dat z jiných zdrojů rozhodne, jak zprávu směrovat. Ve většině jednoduchých případů výměna zvažuje jedno klíčové pole, které nazýváme směrovací klíč . Směrovací klíč je virtuální adresa, kterou může server Exchange použít k rozhodnutí, zda odeslat zprávu. Pro směrování z bodu do bodu je klíčem směrování obvykle název fronty zpráv. U směrování pub-sub je směrovacím klíčem obvykle hodnota hierarchie tématu (téma – viz publikace/subscruber). Ve složitějších případech lze směrovací klíč kombinovat se směrováním podle polí hlavičky zprávy a/nebo obsahu zprávy.
Když klientská aplikace vytvoří frontu zpráv, může určit následující vlastnosti:
Zpráva AMQP se skládá ze sady vlastností a neveřejného obsahu. Novou zprávu vytvoří výrobce pomocí klientského API AMQP. Producent ke zprávě přidá obsah a případně nastaví některé vlastnosti zprávy. Producent označí zprávu směrovací informací, která vypadá jako adresa, ale může to být cokoliv. Producent poté odešle zprávu k výměně . Když zpráva dorazí na server, Exchange ji (obvykle) směruje do sady front, které také existují na serveru. Pokud zpráva není směrovatelná, burza ji může zahodit nebo vrátit do aplikace. Výrobce rozhodne, jak naložit s nesměrovatelnými zprávami.
Jedna zpráva může existovat v mnoha frontách zpráv. Server to může zpracovat různými způsoby, jako je kopírování zprávy pomocí počítání referencí atd. Interoperabilita to neovlivňuje. Pokud je však zpráva směrována do více front zpráv, je v každé frontě zpráv identická. Neexistuje zde žádný jedinečný identifikátor, který by rozlišoval mezi různými kopiemi.
Když zpráva dorazí do fronty zpráv, okamžitě se ji pokusí doručit spotřebiteli prostřednictvím AMQP. Pokud to není možné, pak se zpráva uloží do fronty zpráv (na žádost výrobce do paměti nebo na disk ) a čeká, až bude spotřebitel připraven. Pokud není žádný spotřebitel , může fronta vrátit zprávu producentovi přes AMQP (opět, pokud o to producent požádal).
Když může fronta zpráv doručit zprávu spotřebiteli , odebere zprávu ze svého interního úložiště. To se může stát okamžitě nebo poté, co spotřebitel potvrdí, že úspěšně dokončil svou práci, zpracoval zprávu. Spotřebitel si vybere, jak a kdy budou zprávy „potvrzeny“. spotřebitel může zprávu také odmítnout (negativní potvrzení).
Zprávy producenta a potvrzení spotřebitelů jsou seskupeny do transakcí. Když aplikace hraje obě role, což je častý případ, provádí smíšenou práci odesílání zpráv a odesílání potvrzení a poté potvrzení nebo vrácení transakce.
Doručování zpráv ze serveru spotřebiteli je netransakční.
Producer je klientská aplikace, která publikuje zprávy k výměně .
Analogicky s e-mailovým zařízením můžete vidět, že výrobce neposílá zprávy přímo do fronty (fronty zpráv). Jakékoli jiné chování by narušilo abstrakci v modelu AMQ. Bylo by to podobné životnímu cyklu e-mailové zprávy: vyřešení e-mailu, obcházení směrovacích tabulek MTA a přímý zásah do poštovní schránky. To by znemožnilo vložit mezifiltrování a zpracování, jako je detekce spamu.
Model AMQ využívá stejný princip jako e-mailový systém: všechny zprávy jsou odesílány na jedinou burzu nebo MTA , která kontroluje zprávy na základě pravidel a informací, které jsou skryté před odesílatelem, a směruje je do distribučních bodů, které jsou také skryté před odesílatel. (a nasměruje je na místa odevzdání, která jsou také skryta před odesílatelem - zde jsou distribuční místa místa odevzdání z dokumentace).
Consumer je klientská aplikace, která přijímá zprávy z fronty zpráv.
Naše e-mailová analogie se začíná rozpadat, když se podíváme na spotřebitele (příjemce). E-mailoví klienti jsou pasivní – mohou číst schránky, ale nemají žádný vliv na to, jak jsou tyto schránky obsazeny. S AMQP může být spotřebitel také pasivní, stejně jako e-mailoví klienti. To znamená, že můžeme napsat aplikaci, která naslouchá konkrétní frontě zpráv a jednoduše zpracovává příchozí informace. V tomto případě musí být fronta zpráv připravena před spuštěním aplikace a musí k ní být „připojena“.
Spotřebitel má také následující vlastnosti:
Je to jako mít poštovní systém, který na úrovni protokolu dokáže:
Většina integračních architektur tuto úroveň složitosti nepotřebuje. Většina uživatelů AMQP potřebuje základní funkce ihned po vybalení. AMQP to poskytuje následujícím způsobem:
Výsledkem je, že základní vazba umožňuje producentovi posílat zprávy přímo do fronty zpráv, čímž emuluje nejjednodušší schéma pro odesílání zpráv do přijímače, které by lidé očekávali od tradičního middlewaru.
Základní vazba nebrání použití fronty zpráv ve složitějších návrzích. Umožňuje vám používat AMQP bez konkrétního pochopení vazebných a výměnných mechanismů.
Tato část popisuje proces interakce mezi aplikací a serverem
Middleware je složitý a při návrhu struktury protokolu se jeho tvůrci snažili tuto složitost zkrotit. Jejich přístupem bylo modelovat tradiční API založené na třídách, které obsahují metody, přičemž každá metoda dělá přesně jednu věc a dělá ji dobře. Výsledkem je velká sada příkazů, která je však relativně snadno pochopitelná.
Příkazy AMQP jsou seskupeny do tříd. Každá třída pokrývá určitou funkční oblast. Některé třídy jsou volitelné – každý peer implementuje třídy, které musí podporovat.
Existují dva různé způsoby dialogu:
Pro zjednodušení zpracování metody definujeme samostatné odpovědi pro každý synchronní požadavek. To znamená, že jedna metoda se nepoužívá k zodpovězení dvou různých požadavků. To znamená, že partner při odesílání synchronního požadavku může přijímat a zpracovávat příchozí metody, dokud není přijata jedna z platných synchronních odpovědí. Tím se AMQP odlišuje od tradičnějších protokolů RPC.
Metoda je formálně definována jako synchronní požadavek, synchronní odpověď (na konkrétní požadavek) nebo asynchronní. Nakonec je každá metoda formálně definována jako na straně klienta (tj. server-klient) nebo na straně serveru (klient-server).
AMQP je navržen tak, aby byl srovnatelný s middleware API. Proces párování je poněkud intelektuální, tzn. chápe, že ne všechny metody a ne všechny argumenty mají pro aplikaci smysl, ale je také mechanická, tzn. nastavením určitých pravidel lze všechny metody sladit bez ručního zásahu.
Výhodou toho je, že když se vývojáři naučí sémantiku AMQP, najdou stejnou sémantiku poskytovanou v jakémkoli rámci, který používají.
Příklad metody Queue.Declare:
Fronta . prohlásit fronta = moje . fronta auto - smazat = PRAVDA exkluzivní = NEPRAVDALze jej převést na síťový rámec:
+--------+---------+----------+-----------+-------- ----+ | Fronta | prohlásit | můj _ fronta | 1 | 0 | +--------+---------+----------+-----------+-------- ----+ název metody třídy auto - smazat exkluzivníNebo v metodě API na vysoké úrovni
Fronta . Declare ( "my.queue" , TRUE , FALSE );Asynchronní metoda odpovídající logice v pseudokódu:
odeslat metodu na serverSynchronní metoda odpovídající logice v pseudokódu:
odeslat metodu požadavku na server opakovat čekat na odpověď ze serveru pokud je odezva asynchronní metodou _ způsob zpracování ( obvykle dodaný nebo vrácený obsah ) _ jiný potvrdit , že tato metoda je platnou odpovědí na požadavek opakování výstupu konec - kdyby konec - opakovatStojí za zmínku, že u většiny aplikací může být middleware zcela skrytý v technických vrstvách systému a že skutečné použité API je méně důležité než skutečnost, že middleware je robustní a funkční.
Chatty protokol je pomalý. Aktivně využíváme asynchronii v případech, kdy je problém s výkonem. To je obvykle místo, kde posíláme obsah od jednoho peer druhému. Metody odesíláme co nejrychleji, aniž bychom čekali na potvrzení. Tam, kde je to nutné, implementujeme okna a omezování na vyšší úrovni, jako je spotřebitelská úroveň.
Protokol se obejde bez upozornění, protože implementuje model tvrzení pro všechny události. Buď uspěje, nebo je vyvolána výjimka? která uzavře kanál nebo spojení.
V AMQP nejsou žádná oznámení. Úspěšná událost – tiše, neúspěch – se prohlásí. Když aplikace potřebuje explicitní sledování úspěchů a neúspěchů, měla by používat transakce.
Spojení je navrženo tak, aby bylo odolné a zvládlo mnoho kanálů.
Životní cyklus připojeníInformace se nevyměňují za chyby neúplně otevřených spojení. Hostitel, u kterého došlo k chybě, by měl bez dalšího upozornění zavřít soket.
AMQP je vícekanálový protokol. Kanály poskytují možnost multiplexovat těžké TCP/IP spojení do více lehkých spojení. Proto je protokol „přívětivější k firewallu“, protože využití portu je předvídatelné. Znamená to také, že lze snadno používat tvarování provozu a další síťové funkce QoS.
Kanály jsou na sobě nezávislé a mohou provádět různé funkce současně s jinými kanály, přičemž dostupná šířka pásma je rozdělena mezi souběžné úlohy.
Očekává se a je podporováno, že klientské aplikace s více vlákny mohou často používat model „kanál na vlákno“ pro usnadnění vývoje. Naprosto přijatelné je však také otevření více připojení k jednomu nebo více serverům AMQP z jednoho klienta. Životní cyklus kanálu je následující:
Umožňuje aplikaci spravovat instance Exchange na serveru. Tato třída umožňuje aplikaci napsat svůj vlastní skript pro zpracování zpráv, aniž by se spoléhala na jakoukoli konfiguraci.
Poznámka: Většina aplikací tuto úroveň složitosti nepotřebuje a starší middleware tuto sémantiku pravděpodobně nepodporuje.
Životní cyklus burzyTřída fronty umožňuje aplikaci spravovat fronty zpráv na serveru. Toto je základní krok téměř ve všech aplikacích, které přijímají zprávy, alespoň pro ověření, že očekávaná fronta zpráv skutečně existuje.
Protokol poskytuje dva životní cykly fronty:
AMQP implementuje mechanismus odběru témat ve formě front zpráv. To umožňuje zajímavé struktury, kde může být předplatné vyrovnáváno zatížení v rámci skupiny spolupracujících předplatitelských aplikací.
Životní cyklus předplatnéhoZákladní třída implementuje schopnosti zasílání zpráv popsané v této specifikaci. Podporuje následující sémantiku:
AMQP podporuje dva typy transakcí:
Třída Transaction (“tx”) poskytuje aplikacím přístup k druhému typu transakcí, transakcím na lokálním serveru. Sémantika třídy je následující:
Transakce se týkají publikování obsahu a potvrzení, nikoli doručení. Proto vrácení nezařadí do fronty a nespustí opětovné doručení. Klient může tyto zprávy potvrdit v další transakci.
Tato část vysvětluje, jak se příkazy mapují na protokol na úrovni drátu .
AMQP je binární protokol. Informace jsou organizovány do rámců různých typů. Rámce obsahují metody protokolu a další informace. Všechny rámce mají stejný obecný formát: záhlaví rámce, užitečné zatížení a konec rámce. Formát užitečného zatížení rámce závisí na typu rámce.
Na transportní úrovni se předpokládá použití TCP/IP stacku nebo analogů.
V rámci jednoho zásuvkového připojení může existovat několik nezávislých toků ovládání, nazývaných kanály. Každý snímek je očíslován číslem kanálu. Prokládáním svých rámců sdílejí různé kanály toto spojení. Pro jakýkoli daný kanál jsou rámce prováděny v přísném pořadí, které lze použít k řízení analyzátoru protokolu (obvykle stavového automatu).
Vytváříme rámce pomocí malé sady datových typů, jako jsou bity, celá čísla, řetězce a tabulky polí. Pole rámců jsou pevně zabalena, aniž by byla zpomalená nebo obtížně analyzovatelná. Je relativně snadné vytvořit rámovací vrstvu mechanicky ze specifikací protokolu.
Formátování na úrovni drátu je navrženo tak, aby bylo škálovatelné a dostatečně univerzální pro použití v libovolných protokolech vysoké úrovně (nejen AMQP). Předpokládáme, že AMQP se bude časem rozšiřovat, zlepšovat a jinak měnit a formát na úrovni drátu to bude podporovat.
Datové typy AMQP používané v rámcích:
Klient a server vyjednají protokol. To znamená, že když se klient připojí, server nabídne určité možnosti, které může klient přijmout nebo změnit. Když se oba shodnou na výsledku, spojení se považuje za navázané. Vyjednávání je užitečné, protože umožňuje nastavit předvolby připojení.
Ke koordinaci dochází v několika aspektech:
Dohodnuté limity mohou oběma stranám umožnit předem přidělit vyrovnávací paměti klíčů, čímž se zabrání uváznutí. Každý příchozí rámec buď dodržuje vyjednané limity a je tedy bezpečný, nebo je překračuje, v takovém případě druhá strana selhala a musí být deaktivována. To je velmi dobře v souladu s filozofií AMQP „buď to funguje, jak má, nebo nefunguje vůbec“.
Oba uzly vyjednávají limity na nejnižší dohodnutou hodnotu následovně:
TCP/IP stack - pracuje se streamy, nemá vestavěný mechanismus vymezování rámců. Stávající protokoly řeší tento problém několika různými způsoby:
Všechny rámce se skládají ze záhlaví (7 oktetů), užitečného zatížení libovolné velikosti a oktetu „konce rámce“, který detekuje poškozené rámce:
0 1 3 7 velikost + 7 velikost + 8 +------+---------+------------+ +------------+ +--- ---------+ | typ | kanál | velikost | | užitečné zatížení | | rám - konec | +------+---------+------------+ +------------+ +--- ---------+ oktet krátký dlouhý oktet oktet _Rámeček se čte takto:
V realistických implementacích, kde jde o výkon, použijeme „ukládání do vyrovnávací paměti před čtením“ nebo „shromažďování čtení“, abychom se vyhnuli provádění tří samostatných systémových volání pro čtení rámce.
Rámce metod nesou příkazy protokolu na vysoké úrovni (které nazýváme "metody"). Jeden rámec metody nese jednu instrukci. Užitná zátěž rámce metody má následující formát:
0 2 4 +----------+----------- + ----------------- | třída - id | metoda - id | argumenty ... +----------+----------- + ----------------- krátké krátké ...S rámcem metody se zachází takto:
1. Čtení rámce metody užitečného zatížení.
2. Jeho rozbalení do struktury. Tato metoda má vždy stejnou strukturu, takže ji můžete rychle rozbalit
3. Zkontrolujte, zda je tato metoda v aktuálním kontextu povolena.
4. Kontrola platnosti argumentů metody.
5. Provedení této metody.
Tělo rámce metody je vytvořeno jako seznam datových polí AMQP (bity, celá čísla, řetězce a tabulky řetězců). Zařazovací kód je triviálně generován přímo ze specifikací protokolu a může být velmi rychlý.
Obsah jsou data aplikace, která přenášíme z klienta na klienta prostřednictvím serveru AMQP. Obsah je, zhruba řečeno, soubor vlastností plus binární část dat. Sada povolených vlastností je definována základní třídou a tvoří „rámec hlavičky obsahu“. Data mohou být libovolné velikosti a mohou být rozdělena do několika (nebo mnoha) bloků, z nichž každý tvoří „kostru těla obsahu“.
Když se podíváme na snímky pro konkrétní kanál, jak jsou přenášeny po drátě, můžeme vidět něco takového:
[ metoda ] [ metoda ] [ hlavička ] [ tělo ] [ tělo [ metoda ] ...Některé metody (jako Basic.Publish , Basic.Deliver atd.) jsou formálně definovány jako obsahové. Když partner odešle takový rámec metody, vždy za ním následuje hlavička obsahu a několik rámců těla obsahu nebo bez nich. Záhlaví rámce obsahu má následující formát:
0 2 4 12 14 +----------+--------+-----------+----------------+ ---------------- _ _ | třída - id | hmotnost | velikost těla | vlajky majetku | seznam nemovitostí ... +----------+--------+-----------+----------------+ ---------------- _ _ krátký krátký dlouhý dlouhý krátký zbytek ...Tělo obsahu jsme umístili do samostatných rámců (namísto toho, abychom jej zahrnuli do metody), takže AMQP může podporovat metody „nulové kopie“, kde obsah není nikdy zařazen ani kódován. Vlastnosti obsahu vkládáme do jejich vlastního rámce, aby příjemci mohli selektivně vyřadit obsah, který nechtějí zpracovávat.
Heartbeat je technika navržená tak, aby potlačila jednu z funkcí TCP/IP, konkrétně jeho schopnost zotavit se z přerušeného fyzického připojení, které se ukončí až po poměrně dlouhém časovém limitu. V některých scénářích potřebujeme velmi rychle vědět, zda je peer mimo provoz nebo nereaguje z jiných důvodů (například se zasekne ve smyčce). Vzhledem k tomu, že heartbeat lze provádět na nízké úrovni, budeme to implementovat jako speciální typ rámce, který se vyměňuje mezi uzly na transportní vrstvě, spíše než jako metodu třídy.
AMQP používá výjimky pro zpracování chyb. Jakákoli provozní chyba (nenalezena fronta zpráv, nedostatečná přístupová práva atd.) spustí výjimku kanálu. Jakákoli strukturální chyba (špatný argument, špatná sekvence metod atd.) má za následek výjimku připojení. Výjimka uzavře kanál nebo připojení a vrátí kód odpovědi a tělo odpovědi klientské aplikaci. Používáme 3místný kód odpovědi plus textové schéma odpovědi, které se používá v HTTP a mnoha dalších protokolech.
O připojení nebo kanálu se říká, že je „otevřený“ pro klienta, když odešle Open, a pro server, když odešle Open-Ok. Od této chvíle musí partner, který chce uzavřít kanál nebo spojení, tak učinit pomocí protokolu handshake, který je zde popsán.
Uzavření kanálu nebo připojení z jakéhokoli důvodu - normálního nebo výjimečného - musí být provedeno opatrně. Náhlé zavření nejsou vždy rychle detekovány a po výjimce můžeme ztratit kódy odezvy na chybu. Správný návrh je ručně vyjednat uzavření tak, aby se kanál/spojení uzavřelo až poté, co jsme si jisti, že si druhá strana uvědomuje situaci.
Když se partner rozhodne ukončit kanál nebo připojení, odešle metodu Close. Přijímací uzel musí reagovat na uzavření pomocí Close-Ok a poté mohou obě strany uzavřít svůj kanál nebo spojení. Všimněte si, že pokud partneři ignorují Close, může dojít k zablokování, pokud oba partneři pošlou Close ve stejnou dobu.
Je možné číst a zapisovat rámce AMQP přímo z aplikace, ale to by byl špatný design. I ta nejjednodušší konverzace AMQP je mnohem složitější než například HTTP a vývojáři aplikací nepotřebují rozumět věcem, jako jsou binární formáty rámců, aby mohli odeslat zprávu do fronty zpráv. Doporučená architektura klienta AMQP se skládá z několika úrovní abstrakce:
Obvykle také existuje určitá úroveň I/O, která může být velmi jednoduchá (synchronní soket čtení a zápis) nebo komplexní (plně asynchronní vícevláknové I/O). Tento diagram ukazuje obecnou doporučenou architekturu:
+------------------------+ | aplikace | +-----------+------------+ | +------------------------+ +---| Vrstva API |---- Klientská vrstva API -----+ | +-----------+------------+ | | | | | +-----------------------+ +----------------+ | | | Správce připojení +----+ Vrstva rámování | | | +-----------+------------+ +-------+ | | | | | +------------------------+ | +---| Asynchronní I / O vrstva |-------------------------+ +-----------+------------+ | ------- - - - - Síť - - - - -------Když v tomto dokumentu mluvíme o „klientském API“, máme na mysli všechny vrstvy pod aplikací (i/o, rámování, správce připojení a vrstvy API. O „klientském API“ a „aplikaci“ obvykle mluvíme jako o dvou samostatných věcech, kde aplikace používá klientské API ke komunikaci s middlewarovým serverem.
Zpráva je atomární procesorová jednotka směrovacího a middlewarového systému řazení do fronty. Zprávy obsahují obsah, který se skládá z hlavičky obsahu obsahujícího sadu vlastností a těla obsahu obsahujícího neprůhledný blok binárních dat.
Zpráva může odpovídat mnoha různým entitám aplikace:
Zprávy mohou být trvalé. Trvalá zpráva je bezpečně uložena na disku a je zaručeno, že bude doručena i v případě velkého výpadku sítě, selhání serveru, přetečení atd.
Zprávy mohou mít přednost. Zpráva s vysokou prioritou je odeslána před zprávami s nižší prioritou čekajícími ve stejné frontě zpráv. Když je potřeba zahodit zprávy, aby byla zachována určitá úroveň kvality služeb, server nejprve zahodí zprávy s nízkou prioritou.
Server NESMÍ upravovat těla obsahu zpráv, které přijímá a předává spotřebitelským aplikacím. Server MŮŽE přidat informace do záhlaví obsahu, ale NESMÍ odstraňovat nebo upravovat existující informace.
Virtuální hostiteléVirtuální hostitel je část dat na serveru, administrativní pohodlí, které se ukáže jako užitečné pro ty, kteří chtějí poskytovat AMQP jako službu na sdílené infrastruktuře.
Virtuální hostitel obsahuje svůj vlastní jmenný prostor, sadu výměn, fronty zpráv a všechny související objekty. Každé připojení musí být spojeno s jedním virtuálním hostitelem.
Klient si po ověření vybere virtuálního hostitele v metodě Connection.Open. To znamená, že schéma ověřování serveru je společné pro všechny virtuální uzly na tomto serveru. Použité schéma autorizace však může být jedinečné pro každého virtuálního hostitele. To by mělo být užitečné pro sdílenou hostingovou infrastrukturu. Správci, kteří vyžadují různá schémata ověřování pro každého virtuálního hostitele, musí používat samostatné servery
Všechny kanály v rámci připojení pracují se stejným virtuálním hostitelem. Neexistuje způsob, jak kontaktovat jiného virtuálního hostitele na stejném připojení, a neexistuje způsob, jak přepnout na jiného virtuálního hostitele, aniž by bylo připojení zrušeno a začalo znovu.
Protokol nenabízí žádné mechanismy pro vytváření nebo konfiguraci virtuálních hostitelů - to se děje blíže nespecifikovaným způsobem v rámci serveru a je zcela závislé na implementaci.
VýměnyExchange je agent pro směrování zpráv uvnitř virtuálního hostitele. Instance výměny (kterou běžně označujeme jako "výměna") přijímá zprávy a informace o směrování - zejména směrovací klíč - a buď předává zprávy do front zpráv nebo interním službám. Ústředny jsou pojmenovány podle jednotlivých virtuálních hostitelů.
Aplikace mohou volně vytvářet, sdílet a ničit instance Exchange v rámci své autority.
Výměny mohou být trvalé, dočasné nebo automaticky smazané. Trvalé výměny existují, dokud nejsou odstraněny. Dočasné výměny existují až do vypnutí serveru. Automaticky odstraněné výměny existují, dokud se již nepoužívají.
Server poskytuje specifickou sadu typů výměny. Každý typ výměny implementuje specifické mapování a algoritmus, jak je definováno v další části. AMQP předepisuje malý počet typů výměn a doporučuje několik dalších. Kromě toho může každá implementace serveru přidat své vlastní typy výměny.
Výměna může směrovat jednu zprávu do více front zpráv paralelně. Tím se vytvoří více instancí zpráv, které se spotřebovávají nezávisle na sobě.
Typ přímé výměnytyp přímé výměny funguje takto:
Server MUSÍ implementovat přímou výměnu a MUSÍ předdefinovat v každém virtuálním hostiteli alespoň dvě přímé výměny: jednu s názvem amqp.direct a jednu bez veřejného jména , která slouží jako výchozí výměna pro zpracování veřejných metod.
Všimněte si, že fronty zpráv lze kontaktovat pomocí jakékoli platné hodnoty klíče směrování, ale nejčastěji budou fronty zpráv kontaktovány pomocí jejich vlastního jména jako klíče směrování.
Zejména všechny fronty zpráv BY MĚLY být automaticky vázány na výměnu bez veřejného jména s použitím názvu fronty zpráv jako směrovacího klíče.
Typ výměny FanoutFanout Exchange funguje takto:
Návrh a implementace Fanout Exchange je triviální. Tento typ výměny a předem deklarovaný název amq.fanout jsou povinné.
Typ výměny tématVýměna témat funguje takto:
Směrovací klíč používaný pro výměnu témat se musí skládat ze slov oddělených tečkami. Minimální velikost slova je 0 znaků. Každé slovo může obsahovat písmena AZ a az a také číslice 0-9.
Vzor směrování se řídí stejnými pravidly jako směrovací klíč s dodatkem, že * odpovídá jednomu slovu a # odpovídá žádnému nebo více slovům. Směrovací schéma *.stock.# tedy odpovídá směrovacím klíčům usd.stock a eur.stock.db, ale nikoli stock.nasdaq.
Jedním z navrhovaných schémat pro Topic Exchange je ponechat sadu všech známých směrovacích klíčů a aktualizovat ji, když vydavatelé použijí nové směrovací klíče. Můžete definovat všechny vazby pro daný směrovací klíč a tak rychle najít fronty zpráv pro zprávu. Tento typ výměny je volitelný.
Server musí implementovat typ výměny témat, v takovém případě musí server nejprve deklarovat alespoň jednu výměnu témat s názvem amq.topic v každém virtuálním hostiteli.
Typ výměny záhlavítyp výměny hlaviček funguje takto:
Porovnávací algoritmus je řízen speciálním vazebným argumentem předaným jako pár název-hodnota v tabulce argumentů. Tento argument se nazývá „X-match“. Může nabývat jedné ze dvou hodnot, které určují, jak se při párování zachází s jinými páry hodnot názvu v tabulce:
Pole v argumentech vazby odpovídá poli ve zprávě, pokud je splněna následující podmínka: buď pole v argumentech vazby nemá žádnou hodnotu a pole se stejným názvem je přítomno v záhlaví zprávy, nebo pokud pole ve vazbě arguments má hodnotu a pole se stejným názvem existuje v záhlaví zpráv a má stejný význam.
Jakékoli pole začínající na 'x -' jiné než 'X-match' je vyhrazeno pro budoucí použití a bude ignorováno
Server MUSÍ implementovat typ výměny záhlaví a server MUSÍ předem deklarovat alespoň jeden typ výměny záhlaví s názvem amq.match v každém virtuálním hostiteli.
Typ výměny systémuTyp výměny systému funguje takto:
Systémové služby začínající na "amq." vyhrazeno pro AMQP. Lze použít všechna ostatní jména. Tento typ výměny je volitelný.
Vlastní typy výměnVšechny názvy vlastních typů výměn musí začínat "x -". Typy výměn, které nezačínají "x -" jsou rezervovány pro budoucí použití ve standardu AMQP.
Fronty zprávFronta zpráv je pojmenovaná FIFO, která obsahuje zprávy z aplikací. Aplikace mohou volně vytvářet, sdílet, používat a ničit fronty zpráv v rámci své autority.
Všimněte si, že pokud existuje více čtenářů z fronty nebo klientských transakcí nebo pomocí prioritních polí nebo pomocí selektorů zpráv nebo optimalizace doručení specifické pro implementaci, fronta nemusí mít skutečné charakteristiky FIFO. Jediným způsobem, jak zaručit FIFO, je mít ve frontě připojený pouze jeden spotřebitel. V těchto případech lze frontu popsat jako „slabé FIFO“.
Fronty zpráv mohou být trvalé, dočasné nebo automaticky odstraňované. Trvalé fronty zpráv existují, dokud nejsou odstraněny. Dočasné fronty zpráv existují, dokud není server vypnut. Fronty automatického mazání trvají, dokud se již nepoužívají.
Fronty zpráv ukládají své zprávy do paměti, na disk nebo do nějaké kombinace těchto dvou. Fronty zpráv jsou pojmenovány podle virtuálního hostitele.
Fronty zpráv obsahují zprávy a distribuují je jednomu nebo více zákaznickým klientům. Zpráva odeslaná do fronty zpráv není nikdy odeslána více než jednomu klientovi, pokud nebyla odmítnuta
Jedna fronta zpráv může obsahovat různé typy obsahu současně a nezávisle. To znamená, že pokud jsou hlavní obsah a obsah souboru odeslány do stejné fronty zpráv, budou na vyžádání nezávisle doručovány spotřebním aplikacím.
VazbyVazba je spojení mezi frontou zpráv a výměnou dat. Vazba definuje směrovací argumenty, které sdělují výměně, které zprávy by měla fronta přijímat. Aplikace vytvářejí a ruší vazby podle potřeby, aby směrovaly tok zpráv do jejich front zpráv. Životnost vazby závisí na frontách zpráv, pro které jsou definovány – když je fronta zpráv zničena, je zničena i její vazba. Konkrétní sémantika metody Queue.Bind závisí na typu výměny.
Spotřebitelé - spotřebiteléTermín spotřebitel používáme k označení jak klientské aplikace, tak entity, která řídí, jak konkrétní klientská aplikace přijímá zprávy z fronty zpráv. Když klient „spustí spotřebitele“, vytvoří na serveru spotřebitelskou entitu. Když klient "zruší spotřebitele", zničí entitu spotřebitele na serveru. Spotřebitelé patří ke stejnému klientskému kanálu a nutí frontu zpráv, aby posílala zprávy klientovi asynchronně.
Kvalita služebKvalita služby určuje rychlost odesílání zpráv. Kvalita služby závisí na typu distribuovaného obsahu. Obecně QoS používá koncept "prefetch" k označení toho, kolik zpráv nebo kolik oktetů dat bude odesláno, než klient zprávu potvrdí. Cílem je odeslat data zprávy s předstihem, aby se snížila latence.
PoděkováníPotvrzení je formální signál z klientské aplikace do fronty zpráv, že úspěšně zpracovala zprávu. Existují dva možné modely ověřování:
Klientské vrstvy mohou samy implementovat explicitní potvrzení různými způsoby, například ihned po přijetí zprávy nebo když aplikace oznámí, že ji zpracovala. Tyto rozdíly neovlivňují AMQP ani interoperabilitu.
řízení tokuŘízení toku je nouzový postup používaný k zastavení toku zpráv od partnera. Funguje stejně mezi klientem a serverem a je implementován příkazem Channel.Flow. Flow Control je jediný mechanismus, který může zastavit nadměrně produktivního vydavatele. Spotřebitel může použít elegantnější mechanismus předběžného načítání okna, pokud používá potvrzení (což obvykle znamená použití transakcí).
Konvence pojmenováníTyto konvence řídí pojmenování entit AMQP. Server a klient musí respektovat tyto konvence:
Metody AMQP mohou z důvodů kompatibility definovat minimální hodnoty (jako je počet spotřebitelů ve frontě zpráv). Tato minima jsou definována v popisu každé třídy.
Vyhovující implementace AMQP by měly implementovat poměrně velkorysé hodnoty pro taková pole, minima jsou určena pouze pro použití na nejméně schopných platformách.
Gramatiky používají tento zápis:
Metody definujeme jako:
Standardní číslo portu AMQP bylo přiděleno IANA jako 5672 pro TCP i UDP. Port UDP vyhrazený pro použití v budoucích implementacích vícesměrového vysílání
Poskytujeme kompletní gramatiku pro AMQP (tato je poskytována pro referenci a možná vás bude zajímat sledování částí, které podrobně popisují různé typy rámců a jejich formáty):
amqp = protokol - hlavička * amqp - jednotka protokol - hlavička = doslovný - protokol AMQP - protokol id - verze doslovný - AMQP = % d65 .77.81.80 ; "AMQP" protokol - id = % d0 ; Musí být 0 protokol - verze = % d0.9.1 ; _ 0-9-1 metoda = metoda - rámec [ obsah ] metoda - rámec = % d1 rámec - metoda vlastností - rámec užitečného zatížení - konec rám - vlastnosti = užitečné zatížení kanálu - velikost kanál = short - uint ; ne - nula užitečné zatížení - velikost = dlouhá - uint metoda - užitečné zatížení = třída - metoda id - id * amqp - pole class - id = % x00 ,01 - % xFF . FF metoda - id = % x00 ,01 - % xFF . FF amqp - pole = BIT / OCTET / krátký - uint / dlouhý - uint / dlouhý - dlouhý - uint / krátký - řetězec / dlouhý - řetězec / časové razítko / pole - tabulka krátký - uint = 2 * OCTET dlouhý - uint = 4 * OCTET dlouhý - dlouhý - uint = 8 * OCTET short - string = OCTET * string - char ; délka + obsah řetězec - char = % x01 .. % xFF long - string = long - uint * OCTET ; délka + obsah časové razítko = long - long - uint ; 64bitový POSIX _ _ pole - tabulka = long - uint * pole - hodnota - pár pole - hodnota - dvojice = pole - název pole - hodnota pole - jméno = krátký - řetězec pole - hodnota = 't' boolean / 'b' short - short - int / 'B' krátký - krátký - uint / 'U' krátké - int / 'u' krátké - uint / 'I' long - int / 'i' dlouho - uint / 'L' long - long - int / 'l' long - long - uint / 'f' plovoucí / 'd' dvojnásobek / 'D' desítkové - hodnota / 's' krátký - řetězec / 'S' dlouhý - řetězec / 'A' pole - pole Časové razítko / 'T' / 'F' pole - tabulka / 'V' ; žádné pole boolean = OCTET ; 0 = NEPRAVDA , jinak PRAVDA short - short - int = OCTET krátký - krátký - uint = OCTET krátký - int = 2 * OCTET dlouhý - int = 4 * OCTET long - long - int = 8 * OCTET float = 4 * OCTET ; IEEE -754 double = 8 * OCTET ; rfc1832 XDR double desítkový - hodnota = měřítko dlouhé - uint měřítko = OCTET ; počet desetinných číslic _ pole - pole = long - int * pole - hodnota ; pole hodnot _ rám - konec = % xCE obsah = % d2 obsah - záhlaví * obsah - tělo obsah - záhlaví = rámec - záhlaví vlastností - rámec užitečného zatížení - konec záhlaví - užitečné zatížení = obsah - obsah třídy - hmotnost obsah - tělo - velikost vlastnost - příznaky vlastnost - seznam obsah - třída = oktet obsah - hmotnost = % x00 obsah - tělo - velikost = dlouhý - dlouhý - uint vlastnost - příznaky = 15 * BIT % b0 / 15 * BIT % b1 vlastnost - příznaky vlastnost - seznam = * amqp - pole obsah - karoserie = % d3 rám - vlastnosti karoserie - užitečné zatížení rám - konec karoserie - užitečné zatížení = * OCTET tep = % d8 % d0 % d0 snímek - konec
Používáme rozšířenou syntaxi BNF definovanou v IETF RFC 2234. Závěrem:
Klient musí zahájit nové připojení odesláním hlavičky protokolu. Toto je 8 oktetová sekvence:
+---+---+---+---+---+---+---+---+ | 'A' | 'M' | 'Q' | 'P' | 0 | 0 | 9 | 1 | +---+---+---+---+---+---+---+---+ 8 oktetůZáhlaví protokolu se skládá z velkých písmen "AMQP" následovaných konstantou %d0 následovanou:
Model vyjednávání protokolu je kompatibilní se stávajícími protokoly, jako je HTTP, které iniciují spojení s konstantním textovým řetězcem, a s firewally, které sledují začátek protokolu, aby se rozhodly, která pravidla na něj použít.
Klient a server vyjednají protokol a verzi následovně:
Příklad:
Klient odešle : Server odpoví : AMQP % d0 .0.9.1 Připojení . startovací metoda AMQP % d0 .1.0.0 AMQP % d0 .0.9.1 < Zavřít připojení > HTTP AMQP % d0.0.9.1 < Zavřít připojení > _Zásady implementace protokolu:
Všechny snímky začínají 7-oktetovým záhlavím, které se skládá z pole typu (oktet), pole kanálu (krátké celé číslo) a pole délky (dlouhé celé číslo):
0 1 3 7 velikost + 7 velikost + 8 +------+---------+---------+ +-------------+ +------ -----+ | typ | kanál | velikost | | užitečné zatížení | | rám - konec | +------+---------+---------+ +-------------+ +------ -----+ oktet krátký dlouhý ' velikost ' oktet oktetAMQP definuje následující typy rámců:
Číslo kanálu je 0 pro všechny rámce, které jsou pro připojení globální, a 1-65535 pro rámce, které odkazují na konkrétní kanály.
Pole velikost je velikost užitečného zatížení, kromě oktetu konce snímku. Zatímco AMQP předpokládá spolehlivý připojený protokol, používáme konec rámce k detekci chyb rámování způsobených nesprávnou implementací klienta nebo serveru.
Zásady implementace protokolu:
Těla rámců metod se skládají z neměnného seznamu datových polí nazývaných "argumenty". Všechna těla metod začínají identifikátory třídy a metody:
0 2 4 +----------+----------- + ----------------- | třída - id | metoda - id | argumenty ... +----------+----------- + ----------------- krátké krátké ...Zásady implementace protokolu:
AMQP má dvě úrovně specifikace datových polí: nativní datová pole používaná pro argumenty metod a datová pole předávaná mezi aplikacemi v tabulkách polí. Tabulky polí obsahují sadu horních indexů nativních datových polí.
AMQP definuje následující typy nativních celých čísel:
Celá čísla a délky řetězců jsou vždy bez znaménka a jsou uloženy v síťovém pořadí bajtů. Nesnažíme se optimalizovat případ, kdy spolu mluví dva nízko-vysoké systémy (např. dva procesory Intel).
Zásady implementace protokolu:
AMQP definuje svůj vlastní typ bitového pole. Bity se shromažďují do celých oktetů. Když se v rámci dotknou dva nebo více bitů, budou zabaleny do jednoho nebo více oktetů, počínaje nejnižším bitem v každém oktetu. Neexistuje žádný požadavek, aby všechny bitové hodnoty v rámci byly souvislé, ale obvykle se tak děje za účelem minimalizace velikosti rámce.
ŘetězceŘetězce AMQP mají proměnnou délku a jsou reprezentovány délkou celého čísla následovaného nulou nebo více datovými oktety. AMQP definuje dva nativní typy řádků:
Časová razítka jsou uložena v 64bitovém formátu POSIX time_t s přesností jedné sekundy. Použitím 64 bitů se vyhneme budoucím problémům se zalamováním souvisejícím s 31bitovými a 32bitovými hodnotami time_t.
Okraje tabulkyPole tabulky jsou dlouhé řetězce obsahující sbalené dvojice název-hodnota. Páry jmen a hodnot jsou zakódovány jako krátký řetězec určující název a oktet určující typ hodnoty, za kterým následuje samotná hodnota. Platné typy polí pro tabulky jsou rozšíření nativních typů celé číslo, bit, řetězec a časové razítko a jsou uvedeny v gramatice. Celočíselná pole s více oktety jsou vždy uložena v síťovém pořadí bajtů.
Zásady implementace protokolu:
Určité specifické metody (Publish, Deliver atd.) zpracovávají obsah. Specifikace jednotlivých metod naleznete v kapitole "Funkční specifikace" Metody, které zpracovávají obsah, tak činí bezpodmínečně.
Obsah se skládá ze seznamu 1 nebo více rámců takto:
Snímky obsahu na konkrétním kanálu jsou přísně sekvenční. To znamená, že je lze smíchat s rámečky pro jiné kanály, ale nelze smíchat dva rámce obsahu ze stejného kanálu a nemohou se navzájem „překrývat“ a rámce obsahu pro stejný obsah nelze smíchat s rámečky metod na stejném kanálu. .. (původní rámce obsahu na konkrétním kanálu jsou přísně sekvenční. To znamená, že mohou být smíchány s rámečky pro jiné kanály, ale žádné dva rámce obsahu ze stejného kanálu se nesmějí míchat ani překrývat, ani rámce obsahu pro jeden obsah nesmí být smíchané s metodami na stejném kanálu.)
Všimněte si, že jakýkoli neobsahový rámec explicitně označuje konec obsahu. Zatímco velikost obsahu je dobře známá z hlavičky obsahu (a tedy i počet rámců obsahu), umožňuje to odesílateli přerušit obsah, aniž by musel zavřít kanál.
Zásady implementace protokolu:
Záhlaví užitečného zatížení obsahu má následující formát:
0 2 4 12 14 +----------+--------+-----------+----------------+ ---------------- _ _ | třída - id | hmotnost | velikost těla | vlajky majetku | seznam nemovitostí ... +----------+--------+-----------+----------------+ ---------------- _ _ krátký krátký dlouhý dlouhý krátký zbytek ...Zásady implementace protokolu:
Obsah těla obsahu je „neprůhledný“ binární blok končící oktetem konce rámce:
+----------------------+ +-----------+ | Neprůhledné binární užitečné zatížení | | rám - konec | +----------------------+ +-----------+Tělo obsahu lze rozdělit do libovolného počtu snímků. Maximální velikost užitečného zatížení rámce je vyjednána oběma partnery během vyjednávání o připojení.
Zásady implementace protokolu:
Snímky srdečního tepu sdělují příjemci, že odesílatel je stále naživu. Frekvence a načasování snímků Heartbeat jsou dohodnuty během nastavování připojení.
Zásady implementace protokolu:
AMQP umožňuje kolegům vytvářet více nezávislých toků řízení. Každý kanál funguje jako virtuální připojení, které sdílí jeden soket:
rámy rámečky rámečky rámečky +-----------+-----------+-----------+-----------+ | kanál | kanál | kanál | kanál | +-----------+-----------+-----------+-----------+ | zásuvka | +-------------------------------------------------- ----+Zásady implementace protokolu:
Server musí zajistit, aby klientská pozorování stavu serveru byla konzistentní.
Následující příklad ukazuje, co v tomto kontextu znamená pozorování klienta:
Záruka viditelnosti zajišťuje, že klient 2 vidí frontu
Server bude považovat kanál za uzavřený, pokud dojde k některé z následujících situací:
Když server uzavře kanál, všechny nepotvrzené zprávy na kanálu jsou označeny k opětovnému doručení. Když server uzavře připojení, odstraní všechny automaticky odstraněné entity patřící k tomuto připojení.
V některých případech ovlivňují synchronní metody žádost-odpověď asynchronní doručování obsahu přes stejný kanál, včetně:
Zásady implementace protokolu:
Pořadí, ve kterém metody procházejí kanálem, je stabilní: metody jsou přijímány ve stejném pořadí, v jakém jsou odesílány. Na transportní vrstvě to zajišťuje protokol TCP/IP. Kromě toho je obsah stabilně zpracováván serverem. Zejména obsah, který sleduje stejnou cestu na serveru, zůstane objednaný. Pro obsah dané priority procházející jedinou cestou definujeme cestu zpracování obsahu jako skládající se z jednoho příchozího kanálu, jedné výměny, jedné fronty a jednoho odchozího kanálu.
Zásady implementace protokolu:
Při použití standardního programovacího modelu „výjimek“ AMQP nesignalizuje úspěch, pouze neúspěch. AMQP definuje dvě úrovně vyloučení:
Formálně dokumentujeme tvrzení v definici každé třídy a metody.
Formát kódu odpovědiKódy odpovědí AMQP se řídí definicí „Závažnosti a teorie kódu odpovědi“ v IETF RFC 2821.