Úvod do protokolu AMQP
AMQP (Advanced Message Queuing Protocol) je aplikační standardní protokol, který poskytuje jednotné messaging služby a je otevřeným standardem pro aplikační protokoly navržené pro middleware orientovaný na zprávy. AMQP je síťový protokol pro předávání asynchronních zpráv mezi procesy.
Klienti a middleware pro zprávy založený na tomto protokolu mohou doručovat zprávy bez omezení různými klientskými a middleware produkty, různými vývojovými jazyky atd.
Hlavními charakteristikami AMQP jsou orientace na zprávy, frontování, směrování (včetně peer-to-peer a publikování/odběru), spolehlivost a bezpečnost. AMQP vynucuje chování poskytovatelů zpráv a klientů, což umožňuje skutečnou interoperabilitu mezi různými dodavateli.
AMQP a JMS
JMS byl pokusem standardizovat raný middleware zpráv, byl standardizován pouze na úrovni API a byl daleko od vytvoření interoperability.
Na rozdíl od JMS je AMQP protokol na úrovni drátu, který popisuje formát dat přenášených sítí, plynoucích v bajtech. Výsledkem je, že jakýkoli nástroj, který dodržuje tento datový formát a vytváří a interpretuje zprávy, je interoperabilní s dalšími kompatibilními nástroji.
Složení jádra AMQP
Výrobce
Produkční novinky.
ConnectionFactory
Továrna, která vyrábí Connection.
Připojení
Připojení, síťové připojení aplikací s Broker TCP/IP/Triple Handshake a Quad Wave.
AMQP připojení jsou obvykle dlouhá spojení. AMQP je protokol na aplikační vrstvě, který využívá TCP k zajištění spolehlivého doručení. AMQP používá autentizační mechanismy a poskytuje ochranu TLS (SSL). Když aplikace již nemusí být připojena k AMQP proxy, musí AMQP spojení plynule uvolnit místo pouhého ukončení TCP připojení.
Kanál
Síťový kanál je lehké spojení postavené na Connection. Téměř všechny operace probíhají v kanálech, což jsou kanály pro čtení a zápis zpráv, a klienti mohou nastavit dvojice pro každý kanál, z nichž každý představuje úkol relace.
Pokud je připojení porovnáváno s optickým vláknem, pak kanál kanálu je porovnáván s jedním z vláken v optickém kabelu. Na spojení lze vytvořit libovolný počet kanálů.
Většina našich obchodních operací probíhá v rozhraní Channel, včetně:
- queueDeclare
- ExchangeDeclare pro přepínač
- queueBind queueBind
- Publikovat zprávu základPublikovat
- Spotřebitelské novinkybasicConsume atd.
Makléř
Přijměte připojení klienta pro implementaci AMQP entitních služeb, jako je rabbitmq.
VirtualHost (webhosting)
Virtuální hosting, používaný pro logickou izolaci, může mít virtuální hostitel několik výměn a front, a stejný virtuální hostitel nemůže mít výměny se stejným názvům.
Pro implementaci více izolovaných prostředí (uživatelé, uživatelské skupiny, switche, fronty atd.) na jednom proxy, AMQP poskytuje koncept virtuálních hostitelů (virtuální hostitelé – vhosty). To je velmi podobné konceptu webhostingu webových serverů, který poskytuje zcela izolované prostředí pro AMQP entity. Po navázání spojení klient AMQP určí, který virtuální hostitel použít.
Výměna
Switch přijímá zprávy a posílá zprávy do vázané fronty na základě směrovacího klíče (bez možnosti ukládání zpráv).
Switch je AMQP entita používaná k odesílání zpráv. Poté, co switch obdrží zprávu, přesměruje ji do jedné nebo nulové fronty. Směrovací algoritmus, který používá, je určen typem přepínače a pravidly vazby.
Typ spínače:
- Přímá výměna
- Výměna fanoutů
- Výměna témat
- Výměna hlaviček
Vlastnosti spínače:
- Název: Název spínače
- Odolnost: Příznak perzistence, který indikuje, zda je tento přepínač přetrvávávající nebo ne
- Automatické mazání: Příznak Mazání, indikujícíKdyž jsou všechny fronty na této burze hotové, zda budou smazány
- Argumenty: Závisí na samotném agentovi
Stav spínače:
Perzistentní switche budou existovat po restartu brokera, zatímco stagingové switche ne (budou muset být znovu deklarovány poté, co je broker opět online).
Výchozí přepínač
Výchozí výměna je ve skutečnosti přímá výměna, která je předem deklarována zprostředkovatelem zpráv a nemá jméno (název je prázdný řetězec).
Výchozí přepínač si můžete představit jako speciální přímo připojený spínač. Výchozí název přepínače: Null string (AMQP výchozí) Výchozí typ vypínače: Přímo připojený přepínač
Při vytváření fronty, pokud není specifikován přepínač, který má být vázaný, automaticky se naváže na výchozí přepínač a směrovací klíč vazby bude stejný jako název fronty.
Přímé spojení se spínačem
Přímo připojený přepínač doručuje zprávy do fronty odpovídajících vazebních klíčů založených na směrovacím klíči, který zpráva nese. Unicastové směrování používané přímým přepínačem pro zpracování zprávy.
Při vytváření fronty, pokud je vázána na přímý přepínač, nemusí uvádět název směrovacího klíče, protože bude mít výchozí název směrovacího klíče, který je stejný jako název fronty.
Fronta přímo připojených přepínačů obvykle rozděluje úkoly mezi více spotřebitelů v cyklu (tomu říkáme polling).
Pracovní postup:
- Při vázání fronty na switch mu přidělte vazební klíč, předpokládejme R;
- Když je zpráva s routovacím klíčem odeslána přímo připojenému switchi, přepínač ji směruje do fronty s routovacím klíčem.
Ventilátorové spínače
Ventilátorový přepínač směruje zprávy všem frontám s ním navázaným, bez ohledu na vázaný směrovací klíč.
Pokud je N front vázáno na sektorový switch, při odeslání zprávy tomuto sektorovému switchi přepínač odešle kopii zprávy všem N frontám samostatně. Ventilátorové spínače se obecně používají k řešení směrování zpráv při vysílání.
Scénáře aplikace:
vysílané zprávy; Funkce skupinového chatu.
Přepínání tématu
Přepínač tématu odesílá zprávy do jedné nebo více front podle směrovacího klíče a typu výměny, a často jej používáme k implementaci různých příspěvků publikování/odběru, tedy publikování odběrů.
Pravidla směrování pro přímo připojené přepínače jsou přísně sladěna, což znamená, že směrovací klíč musí odpovídat klíči Binding před odesláním zprávy frontě. Pravidla směrování pro změnu tématu jsou fuzzy shody, které lze dosáhnout splněním některých pravidel pomocí žolíků.
Stanoví:
- V klíči pro párování mohou být dva speciální znaky * a # pro fuzzy matching. kde * se používá k přiřazení slova, #用于匹配多个单词 (může být nula)
- Směrovací klíč je řetězec oddělený tečkou (každý jednotlivý řetězec oddělený tečkou označujeme slovem)
- Když producent odešle zprávu Směrovací klíč=A.A.A, je splněno pouze A.*.* a bude směrována pouze do fronty 1.
- Když producent odešle zprávu Routing Key=A.B.A, splnění A.*.* a *.B.* bude směrováno do fronty 1 a fronty 2.
- Když producent odešle zprávu Směrovací klíč=A.B.C, pak jsou splněny A.*.* a *.B.* a *.*. C je směrováno do fronty1, fronty2, fronty3.
Scénáře aplikace:
- aktualizace zpráv týkající se kategorií nebo štítků;
- Úkoly na pozadí vykonávané více pracovníky, z nichž každý je zodpovědný za určité specifické úkoly.
Hlavový spínač
Hlavičkové spínače nespoléhají na pravidla shody směrovacího klíče s přiřazením klíčů k směrování zpráv, ale spíše na základě atributu hlaviček v obsahu odeslané zprávy.
Hlavové spínače lze považovat za další projev přímého připojeného spínače. Směrovací klíč přímého přepínače však musí být řetězec a hodnoty atributů hlavičky nejsou tímto omezeny, mohou být dokonce celá čísla nebo hashovací hodnoty (slovníky) atd. Větší flexibilita (ale v praxi hlavové spínače používáme jen zřídka).
Pracovní postup:
- Když je fronta vázána na hlavičkový spínač, je najednou vázáno více hlaviček pro jejich porovnání.
- Příchozí zprávy nesou hlavičku a parametr "x-match". Když je "x-match" nastaveno na "any", lze shodovat jakoukoli hodnotu hlavičky, a když je "x-match" nastaveno na "all", musí být shodována všechna čísla hlavičky.
Shrnutí Switch
Závazný
Virtuální spojení mezi Exchange a frontou.
BindingKey je popis pravidla pro Exchange a Queue bindings. Vazebný klíč určuje, jaký typ směrovacího klíče bude přiřazen aktuálně vázané frontě v aktuální výměně.
Směrovací klíč
Směrovací pravidla, která může virtuální stroj použít k určení, jak směrovat konkrétní zprávu.
Vazba klíče vs. směrovací klíč
- Klíč pro vázání je klíč pro vázání mezi frontou a spínačem;
- Směrovací klíč je informace zaslaná producentem do přepínače;
- Když se klíč Binding a Směrovací klíč shodují, vložte zprávu do odpovídající fronty.
Binding Key je popis pravidla pro Exchange a Queue binding, který se používá k analýze, kdy Exchange přijme zprávu, zpráva přijatá Exchangem bude mít pole pro směrovací klíč a Exchange tento směrovací klíč přirovnává ke všem vázaným klíčům aktuální exchange, a pokud jsou požadavky splněny, bude odeslán do Binding Klíč je vázán na frontu, aby mohl zprávu odeslat.
Vazba klávesy vs. směrovací klíč u různých přepínačů
Výchozí přepínač: Binding Key je název fronty, který nelze přizpůsobit. Směrovací klíč je také název fronty, než může být úspěšně směrován do fronty Přímý přepínač připojení: Binding Key je název fronty, který lze přizpůsobit. Směrovací klíče lze úspěšně směrovat do fronty pouze tehdy, když je Binding Key stejný Ventilátorový spínač: Bez přiřazení klávesy; Samozřejmě, že neexistuje žádný směrovací klíč. Automaticky směrováno do všech front, které jsou navázané na switch Přepínač tématu: vlastní klávesa Binding; Přizpůsobte si směrovací klíč. Směrovací klíč==Vazebný klíč a fuzzy shoda musí být úspěšně směrována do fronty Hlavový spínač: bez klávesy pro zavazování; Samozřejmě, že neexistuje žádný směrovací klíč. Shody na základě atributu hlaviček v obsahu odeslané zprávy
Fronta
Ukládá zprávy, které se chystají aplikovat na konzumaci.
Vlastnosti fronty:
- Název: Název fronty
- Odolnost: Fronta stále existuje i po restartu message brokera
- Exkluzivní: Používá pouze jedno spojení a fronta je smazána po uzavření spojení
- Automatické mazání: Smazáno, když poslední spotřebitel odhlásí odběr
- Argumenty: Někteří zprostředkovatelé zpráv ho používají k dalším funkcím podobným TTL
Vytváření fronty: Fronty lze použít až po jejich deklaraci. Pokud fronta ještě neexistuje, deklarace fronty ji vytvoří. Pokud deklarovaná fronta již existuje a atributy jsou totožné, deklarace nemá na původní frontu žádný vliv. Pokud se atributy v deklaraci liší od těch v existující frontě, je vyhozena výjimka na úrovni kanálu s chybovým kódem 406.
Trvalost fronty: Fronta perzistence je uložena na disku a zůstává tam i při restartu brokera. Fronty, které nejsou persistovány, se nazývají přechodné fronty. Ne všechny scénáře a případy vyžadují trvalost ve frontě.
Persistovaná fronta nezpůsobuje, že zprávy směrované na ni jsou trvalé. Pokud agent zprávy zavěsí a je restartován, fronta perzistence bude během restartu znovu deklarována a v každém případě lze obnovit pouze trvalé zprávy.
Spotřebitel
Zprávy o spotřebitelské spotřebě. V AMQP existují dva způsoby, jak mohou spotřebitelé dostávat čekající zprávy:
Zprávový middleware doručuje zprávy spotřebitelům (push API) Spotřebitelé aktivně dostávají zprávy (pull API) Poznámka: Když více spotřebitelů poslouchá stejnou frontu, zprávy ve frontě budou konzumovány pouze jedním ze spotřebitelů (ne jednou pro každého spotřebitele)
Zpráva
Data přenášená mezi zprávami, službami a aplikacemi se skládají z vlastností a těles.
Atributy upravují zprávy, jako je priorita zpráv, zpoždění a další pokročilé funkce, a hlavní tělo tvoří obsah těla zprávy.
Vlastnosti zprávy:
- Typ obsahu
- Kódování obsahu
- Směrovací klíč
- Režim doručení (trvalý nebo ne)
- Režim doručení (trvalý nebo neperzistentní)
- Priorita zprávy
- Časové razítko publikace zprávy
- Doba expirace
- ID aplikace vydavatele
Tělo zprávy: Kromě atributů obsahují AMQP zprávy také užitečný obsah (data, která zpráva skutečně nese), která je AMQP proxy považována za neprůhledné pole bajtů.
Zprostředkovatel zpráv nekontroluje ani nemění payload. Zprávy mohou obsahovat pouze atributy, aniž by nesly užitečné zatížení. Obvykle používá data v serializovaném formátu jako JSON a pro úsporu peněz protokolové buffery a MessagePacky serializují strukturovaná data pro publikaci jako payload zpráv. AMQP a jeho partneri obvykle používají pole "typ obsahu" a "kódování obsahu" ke komunikaci se zprávami za účelem identifikace užitečných nákladů, ale toto je založeno pouze na konvencích.
Trvalost zpráv: Zprávy jsou publikovány trvalým způsobem a agent AMQP tuto zprávu ukládá na disk. Pokud je server restartován, systém potvrdí, že přijatá zpráva o perzistenci není ztracena.
Pouhé odeslání zprávy do perzistentního switche nebo její směrování do persistentní fronty neznamená, že zpráva je perzistentní: perzistence zprávy závisí zcela na režimu perzistence samotné zprávy.
Trvalé publikování zpráv může mít dopad na výkonnost.
Pracovní proces AMQP
Vydavatel zveřejňuje zprávu prostřednictvím burzy.
Přepínač distribuuje příchozí zprávy frontě vázané na přepínač podle směrovacích pravidel.
Nakonec agent AMQP doručí zprávu spotřebiteli, který se do této fronty přihlásil, nebo ji spotřebitel obdrží sám podle potřeby.
Mechanismus AMQP zasílání zpráv
Potvrzení zprávy
Spotřebitelé občas nedokážou zprávy zpracovat nebo někdy přímo spadnou. A síťové důvody mohou také způsobovat různé problémy. To nám klade otázku, kdy je správný čas, kdy mohou agenti AMQP zprávy smazat.
Dva režimy potvrzení zprávy v AMQP:
Režim automatického potvrzení: Smaž zprávu hned, jak ji pošle uživateli middleware zpráv. (Použitím metody AMQP: basic.deliver nebo basic.get-ok) Režim explicitního potvrzení: Počkejte, až spotřebitel pošle potvrzení, než zprávu smažete. (Použitím metody AMQP: basic.ack) Pokud spotřebitel zavěsí bez odeslání potvrzovacího dokladu, agent AMQP zprávu znovu doručí jinému zákazníkovi. Pokud v tu chvíli nejsou k dispozici žádní spotřebitelé, zprostředkovatel zpráv počká, až se další spotřebitel zaregistruje v této frontě, a pak se pokusí doručit znovu.
Odmítnout zprávy
Když spotřebitel obdrží zprávu, proces zpracování může uspět nebo selhat. Spotřebitel může zprávovému brokerovi (message middleware) oznámit, že zpráva nebyla zpracována (nebo v tomto bodě nedokončena) kvůli "odmítnuté zprávě". Když je zpráva odmítnuta, spotřebitel může zprostředkovači zpráv říct, co s ní má dělat – zničit ji nebo ji vrátit zpět do fronty.
Když je v této frontě pouze jeden spotřebitel, ujistěte se, že zprávu neodmítnete a rozhodnete se ji vrátit zpět do fronty, což způsobí, že se zpráva bude nekonečně opakovat na stejném spotřebiteli.
V AMQP se k provádění operace odmítání zpráv používá metoda basic.odmítnutí. Nicméně basic.reject má omezení: nelze jej použít k odmítnutí více zpráv s potvrzeními. Pokud ale používáte RabbitMQ, můžete použít rozšíření AMQP 0-9-1 nazývané negativní potvrzení (také nazývané nacks) k vyřešení tohoto problému.
Původní:Přihlášení k hypertextovému odkazu je viditelné.
|