Úvod do protokolu AMQP
AMQP (Advanced Message Queuing Protocol) je protokol aplikačnej vrstvy, ktorý poskytuje jednotné komunikačné služby a je otvoreným štandardom pre aplikačné protokoly navrhnuté pre middleware orientovaný na správy. AMQP je sieťový protokol na prenášanie asynchrónnych správ medzi procesmi.
Klienti a middleware na správu založený na tomto protokole môžu doručovať správy bez obmedzení rôznymi klientskymi/middleware produktmi, rôznymi vývojovými jazykmi a podobne.
Hlavné charakteristiky AMQP sú orientácia na správy, frontovanie, smerovanie (vrátane peer-to-peer a publikovania/odberu), spoľahlivosť a bezpečnosť. AMQP presadzuje správanie poskytovateľov správ a klientov, čo umožňuje skutočnú interoperabilitu medzi rôznymi dodávateľmi.
AMQP a JMS
JMS bol pokusom štandardizovať skorý middleware správ, štandardizoval sa len na úrovni API a bol ďaleko od vytvorenia interoperability.
Na rozdiel od JMS je AMQP protokol na úrovni káblov, ktorý popisuje formát dát prenášaných cez sieť, prúdiacich v bajtoch. Výsledkom je, že akýkoľvek nástroj, ktorý dodržiava tento dátový formát a vytvára a interpretuje správy, je interoperabilný s inými kompatibilnými nástrojmi.
Zloženie jadra AMQP
Výrobca
Produkčné novinky.
ConnectionFactory
Továreň, ktorá vyrába Connection.
Pripojenie
Pripojenie, aplikačné sieťové pripojenie s Broker TCP/IP/Triple Handshake a Quad Wave.
AMQP pripojenia sú zvyčajne dlhé spojenia. AMQP je protokol aplikačnej vrstvy, ktorý využíva TCP na zabezpečenie spoľahlivého doručenia. AMQP používa autentifikačné mechanizmy a poskytuje ochranu TLS (SSL). Keď aplikácia už nemusí byť pripojená k AMQP proxy, musí plynulo uvoľniť AMQP spojenie namiesto jednoduchého vypnutia TCP spojenia.
Kanál
Sieťový kanál je ľahké spojenie postavené na Connection. Takmer všetky operácie sa vykonávajú v kanáloch, ktoré slúžia na čítanie a zápis správ, a klienti môžu vytvoriť páry pre každý kanál, z ktorých každý predstavuje session úlohu.
Ak sa Connection porovná s optickým káblom, potom sa kanálový kanál porovnáva s jedným z vlákien v optickom kábli. Na spojení je možné vytvoriť ľubovoľný počet kanálov.
Väčšina našich obchodných operácií prebieha v rozhraní Channel, vrátane:
- queueDeclare
- ExchangeDeclare pre prepínač
- queueBind queueBind
- Zverejniť základnú správu Publikovať
- Spotrebiteľské novinkybasicSpotrebujte, atď.
Maklér
Prijmite pripojenie klienta na implementáciu AMQP entitných služieb, ako je rabbitmq.
VirtualHost (webhosting)
Virtuálny hosting, používaný na logickú izoláciu, môže mať virtuálny hostiteľ niekoľko výmen a frontov, a ten istý virtuálny hostiteľ nemôže mať výmeny s rovnakým názvom.
Na implementáciu viacerých izolovaných prostredí (používateľov, používateľských skupín, prepínačov, fronty atď.) na jednom proxy, AMQP poskytuje koncept virtuálnych hostiteľov (virtuálni hostitelia - vhosty). Toto je veľmi podobné konceptu webhostingu webových serverov, ktorý poskytuje úplne izolované prostredie pre AMQP entity. Keď je spojenie nadviazané, klient AMQP špecifikuje, ktorý virtuálny hostiteľ má použiť.
Výmena
Prepínač prijíma správy a odosiela správy do viazanej fronty na základe smerovacieho kľúča (bez možnosti ukladania správ).
Prepínač je AMQP entita používaná na odosielanie správ. Keď prepínač dostane správu, smeruje ju do jednej alebo nulovej fronty. Smerovací algoritmus, ktorý používa, je určený typom prepínača a pravidlami viazania.
Typ spínača:
- Priama výmena
- Fanout výmena
- Výmena tém
- Výmena hlavičiek
Vlastnosti prepínača:
- Názov: Názov prepínača
- Trvácnosť: Príznak perzistencie, ktorý indikuje, či je tento prepínač pretrvávajúci alebo nie
- Automatické vymazanie: Vlajka vymazať, čo označujeKeď sú všetky fronty cez túto výmenu hotové, či budú vymazané
- Argumenty: Závisí od samotného agenta
Stav prepínača:
Perzistentné prepínače budú existovať po reštarte brokera, zatiaľ čo stagingové prepínače už nie (budú musieť byť znovu deklarované, keď je broker opäť online).
Predvolený prepínač
Predvolená výmena je v skutočnosti priama výmena, ktorá je vopred deklarovaná sprostredkovateľom správ a nemá meno (názov je prázdny reťazec).
Predvolený prepínač si môžete predstaviť ako špeciálny priamo pripojený prepínač.
Predvolený názov prepínača: Null string (AMQP predvolený)
Predvolený typ prepínača: Priamo pripojený prepínač
Pri vytváraní fronty, pokiaľ nie je špecifikovaný prepínač, ktorý má byť viazaný, automaticky sa pripúta k predvolenému prepínaču a názov smerovacieho kľúča viazania bude rovnaký ako názov fronty.
Priame pripojenie k prepínaču
Prepínač s priamym pripojením doručuje správy do fronty zodpovedajúcich viazaných kľúčov na základe smerovacieho kľúča, ktorý správa nesie. Unicast smerovanie používané priamym prepínačom na spracovanie správy.
Pri vytváraní fronty, ak je viazaná na priamy prepínač, nemusí špecifikovať názov smerovacieho kľúča, pretože bude mať predvolený názov smerovacieho kľúča, ktorý je rovnaký ako názov fronty.
Fronta priamo pripojených prepínačov zvyčajne rozdeľuje úlohy viacerým spotrebiteľom v slučke (nazývame to polling).
Pracovný postup:
- Pri viazaní fronty na prepínač mu dajte kľúč viazania, predpokladajúc R;
- Keď je správa s routovacím kľúčom odoslaná priamo pripojenému prepínaču, prepínač ju smeruje do fronty s routovacím kľúčom.
Ventilátorové spínače
Ventilátorový prepínač smeruje správy do všetkých frontov naviazaných naň, bez ohľadu na viazaný smerovací kľúč.
Ak je N frontov viazaných na sektorový prepínač, pri odoslaní správy tomuto sektorovému prepínaču prepínač prepínač odošle kópiu správy do všetkých N frontov samostatne. Ventilátorové spínače sa zvyčajne používajú na riadenie smerovania vysielania správ.
Aplikačné scenáre:
vysielanie správ;
Funkcia skupinového chatu.
Zmena témy
Prepínač témy posiela správy do jednej alebo viacerých frontov podľa smerovacieho kľúča a typu výmeny, a často ho používame na implementáciu rôznych odberov publikovania/odberu, teda publikovania odberov.
Pravidlá smerovania pre prepínače s priamym pripojením sú prísne zladené, čo znamená, že smerovací kľúč musí zodpovedať viazanému kľúču pred odoslaním správy do fronty.
Pravidlá smerovania pre prepínanie tém sú fuzzy zhody, ktoré je možné dosiahnuť splnením niektorých pravidiel prostredníctvom divokých kariet.
Stanovuje:
- V klávese viazania môžu byť dva špeciálne znaky * a # pre fuzzy matching. kde * sa používa na zodpovedanie slovu, #用于匹配多个单词 (môže byť nula)
- Smerovací kľúč je reťazec oddelený bodkami (každý jednotlivý reťazec oddelený bodkou nazývame slovo)
- Keď producent pošle správu Routing Key=A.A.A, je splnená iba A.*.* a bude smerovaná len do queue1.
- Keď producent odošle správu, Routing Key=A.B.A, splnenie A.*.* a *.B.* bude smerované do queue1 a queue2.
- Keď producent odošle správu Routing Key=A.B.C, potom A.*.* a *.B.* a *.* sú uspokojené. C sa smeruje do queue1, queue2, queue3.
Aplikačné scenáre:
- spravodajské aktualizácie týkajúce sa kategórií alebo tagov;
- Úlohy na pozadí vykonávané viacerými pracovníkmi, z ktorých každý je zodpovedný za zvládanie určitých konkrétnych úloh.
Hlavový spínač
Hlavičkové prepínače sa nespoliehajú na zodpovedajúce pravidlá smerovacieho kľúča na viazanie kľúčov na smerovanie správ, ale skôr na základe atribútu hlavičiek v obsahu odoslanej správy.
Hlavové spínače možno považovať za ďalší prejav priameho pripojeného spínača. Avšak smerovací kľúč priameho prepínača musí byť reťazec a hodnoty atribútov hlavičky nie sú týmto obmedzené, môžu byť dokonca celé čísla alebo hashovacie hodnoty (slovníky) a podobne. Viac flexibility (ale v praxi hlavové spínače používame len zriedka).
Pracovný postup:
- Keď je fronta viazaná na hlavičkový prepínač, viacero hlavičiek je viazaných súčasne kvôli zhode.
- Prichádzajúce správy nesú hlavičku a parameter "x-match". Keď je "x-match" nastavené na "any", môže sa zladiť ľubovoľná hodnota hlavičky a keď je "x-match" nastavená na "all", musia sa zhodovať všetky hodnoty hlavičky.
Zhrnutie Switchu
Záväzný
Virtuálne spojenie medzi Exchange a Queue.
BindingKey je popis pravidla pre väzby Exchange a Queue. Kľúč viazania určuje, aký typ smerovacieho kľúča bude priradený aktuálne viazanej fronte v aktuálnej výmene.
Smerovací kľúč
Pravidlá smerovania, ktoré virtuálny stroj môže použiť na určenie, ako smerovať konkrétnu správu.
Kľúč viazania vs. smerovací kľúč
- Binding kľúč je viazací kľúč medzi frontou a prepínačom;
- Routovací kľúč je informácia, ktorú producent posiela prepínaču;
- Keď sa kľúč viazania a smerovací kľúč zhodujú, vložte správu do príslušného frontu.
Binding Key je popis pravidla pre viazanie Exchange a fronty, ktorý sa používa na analýzu, keď Exchange dostane správu, správa prijatá Exchangeom bude mať pole na smerovací kľúč a Exchange tento smerovací kľúč priradí so všetkými viazacími kľúčmi aktuálnej burzy, a ak sú splnené požiadavky, bude odoslaný do väzby Kľúč je viazaný na frontu na odoslanie správy.
Kľúč viazania vs. smerovací kľúč v rôznych prepínačoch
Predvolený prepínač: Binding Key je názov fronty, ktorý nie je možné prispôsobiť. Routovací kľúč je zároveň názov fronty predtým, než môže byť úspešne smerovaný do fronty
Priamy prepínač spojenia: Binding Key je názov fronty, ktorý je možné prispôsobiť. Routovacie kľúče je možné úspešne smerovať do fronty len vtedy, keď je Binding Key rovnaký
Prepínač ventilátora: Žiadny kláves na viazanie; Samozrejme, neexistuje žiadny smerovací kľúč. Automaticky smerované do všetkých frontov viazaných na prepínač
Prepínanie témy: vlastný kláves viazania; Prispôsobte si smerovací kľúč. Smerovací kľúč==Viazaný kľúč a fuzzy zhoda musí byť úspešne smerovaná do fronty
Prepínač hlavy: bez klávesu na viazanie; Samozrejme, neexistuje žiadny smerovací kľúč. Zhody na základe atribútu hlavičiek v obsahu odoslanej správy
Front
Ukladá správy, ktoré aplikácia čoskoro spotrebuje.
Vlastnosti fronty:
- Názov: Názov fronty
- Trvácnosť: Fronta stále existuje aj po reštarte message brokera
- Exkluzívne: Používa len jedno spojenie a fronta sa vymaže, keď sa spojenie uzavrie
- Automatické vymazanie: Vymazané, keď posledný spotrebiteľ odhlási odber
- Argumenty: Niektorí sprostredkovatelia správ ho používajú na vykonávanie ďalších funkcií podobných TTL
Vytváranie fronty:
Fronty je možné použiť až po ich vyhlásení. Ak fronta ešte neexistuje, deklarovanie fronty ju vytvorí. Ak deklarovaná fronta už existuje a atribúty sú identické, deklarácia nemá vplyv na pôvodnú frontu. Ak sa atribúty v deklarácii líšia od tých v existujúcej fronte, vyhodí sa výnimka na úrovni kanála s chybovým kódom 406.
Pretrvávanie fronty:
Persistenčná fronta je uložená na disku a zostáva tam aj po reštarte brokera. Fronty, ktoré nie sú perperentné, sa nazývajú prechodné rady. Nie všetky scenáre a prípady vyžadujú trvalosť vo fronte.
Pretrvávajúca fronta nespôsobuje, že správy smerované na ňu sú trvalé. Ak sa message agent založí a reštartuje, perzistenčná fronta sa počas reštartu znovu deklaruje a v každom prípade je možné obnoviť len pretrvávajúce správy.
Spotrebiteľ
Správy o spotrebiteľskej spotrebe. V AMQP existujú dva spôsoby, ako môžu spotrebitelia dostať čakajúce správy:
Middleware na správu doručuje správy spotrebiteľom (push API)
Spotrebitelia aktívne prijímajú správy (pull API)
Poznámka: Keď viacerí spotrebitelia počúvajú tú istú frontu, správy vo fronte budú spotrebované iba jedným zo spotrebiteľov (nie raz pre každého spotrebiteľa)
Správa
Dáta prenášané medzi správami, službami a aplikáciami pozostávajú z vlastností a telies.
Atribúty upravujú správy, ako je priorita správy, oneskorenie a ďalšie pokročilé funkcie, a hlavnou časťou je obsah tela správy.
Vlastnosti správy:
- Typ obsahu
- Kódovanie obsahu
- Smerovací kľúč
- Režim doručenia (trvalý alebo nie)
- Režim doručenia (trvalý alebo neperzistívny)
- Priorita správy
- Časová pečiatka publikovania správ
- Doba vypršania
- ID aplikácie vydavateľa
Telo správy:
Okrem atribútov obsahujú AMQP správy aj payload (dáta, ktoré správa skutočne nesie), ktoré AMQP proxy považuje za nepriehľadné pole bajtov.
Sprostredkovateľ správ nekontroluje ani neupravuje payload. Správy môžu obsahovať iba atribúty bez toho, aby niesli užitočný náklad. Zvyčajne používa dáta v serializovanom formáte ako JSON a na úsporu peňazí protokolové buffery a MessagePacky serializujú štruktúrované dáta na publikovanie ako payload správ. AMQP a jeho partneri zvyčajne používajú polia "typ obsahu" a "kódovanie obsahu" na komunikáciu so správami na identifikáciu užitočných dát, ale toto je založené len na konvenciách.
Pretrvávanie správ:
Správy sú publikované trvalým spôsobom a AMQP agent túto správu ukladá na disk. Ak sa server reštartuje, systém potvrdí, že prijatá správa o perzistencii sa nestratila.
Jednoduché odoslanie správy do perzistentného prepínača alebo jej smerovanie do persistentnej fronty neznamená, že správa bude perzistentná: perzistencia správy závisí výlučne od režimu perzistencie samotnej správy.
Trvalé publikovanie správ môže mať vplyv na výkon.
Pracovný proces AMQP
Vydavateľ zverejňuje správu prostredníctvom Exchange.
Prepínač rozdeľuje prichádzajúce správy do fronty viazanej na prepínač podľa pravidiel smerovania.
Nakoniec AMQP agent doručí správu spotrebiteľovi, ktorý sa prihlásil na odber tejto fronty, alebo ju spotrebiteľ dostane sám podľa potreby.
Mechanizmus správ AMQP
Potvrdenie správy
Spotrebitelia občas nedokážu spracovať správy alebo niekedy priamo spadnú. A sieťové dôvody môžu tiež spôsobiť rôzne problémy.
To nám kladie otázku, kedy je správny čas, aby agenti AMQP vymazali správy.
Dva režimy potvrdenia správy v AMQP:
Režim automatického potvrdenia: Vymažte správu hneď, ako ju pošle spotrebiteľovi middleware správ. (Použitím metódy AMQP: basic.deliver alebo basic.get-ok)
Režim explicitného potvrdenia: Počkajte, kým spotrebiteľ pošle potvrdenie pred vymazaním správy. (Použitím metódy AMQP: basic.ack)
Ak spotrebiteľ zloží bez odoslania potvrdenia, agent AMQP doručí správu inému spotrebiteľovi. Ak v tom čase nie sú k dispozícii žiadni spotrebitelia, sprostredkovateľ správ čaká, kým sa ďalší spotrebiteľ zaregistruje v tejto fronte, a potom sa pokúsi doručiť znova.
Odmietnuť správy
Keď spotrebiteľ dostane správu, proces spracovania môže byť úspešný alebo neúspešný. Spotrebiteľ môže sprostredkovateľovi správ (middleware) oznámiť, že správa nebola spracovaná (alebo v tomto bode nedokončená) kvôli "zamietnutej správe".
Keď je správa odmietnutá, spotrebiteľ môže sprostredkovateľovi správ povedať, čo má so správou urobiť – zničiť ju alebo ju vrátiť späť do fronty.
Keď je v tejto fronte len jeden spotrebiteľ, uistite sa, že správu neodmietnete a rozhodnete sa ju vrátiť späť do fronty, čo spôsobí, že sa správa bude nekonečne opakovať na tom istom spotrebiteľovi.
V AMQP sa používa metóda basic.reject na vykonanie operácie odmietnutia správ. Avšak basic.reject má obmedzenie: nemôžete ho použiť na odmietnutie viacerých správ s potvrdením. Ak však používate RabbitMQ, môžete použiť rozšírenie AMQP 0-9-1 nazývané negatívne potvrdenia (tiež nazývané nacks) na vyriešenie tohto problému.
Originál:Prihlásenie na hypertextový odkaz je viditeľné.
|
Zverejnené 14. 8. 2022 23:22:55
|
|
|
|
