Bevezetés az AMQP protokollba
Az AMQP (Advanced Message Queuing Protocol) egy alkalmazásrétegi szabványos protokoll, amely egységes üzenetküldő szolgáltatásokat nyújt, és nyílt szabvány az alkalmazási szintű protokollok számára, amelyeket üzenetorientált közműszoftverhez terveztek. Az AMQP egy hálózati protokoll, amely aszinkron üzeneteket továbbít folyamatok között.
Az ezen protokollon alapuló kliensek és üzenetközmű anélkül tudnak üzeneteket továbbítani, hogy különböző kliens/middleware termékek, különböző fejlesztői nyelvek stb. korlátoznák őket.
Az AMQP fő jellemzői az üzenetorientáltság, sorba helyezés, útválasztás (beleértve peer-to-peer és publikálás/előfizetést), megbízhatóság és biztonság. Az AMQP érvényesíti az üzenetszolgáltatók és ügyfelek viselkedését, lehetővé téve a valódi interoperabilitást a különböző szolgáltatók között.
AMQP és JMS
A JMS a korai üzenet-közmű szabványosításának kísérlete volt, csak API szinten szabványosította, és messze állt az interoperabilitás megteremtésétől.
A JMS-szel ellentétben az AMQP egy vezetékes szintű protokoll, amely a hálózaton keresztül továbbított adatok formátumát írja le, amely bájtokban áramlik. Ennek eredményeként bármely eszköz, amely ezt az adatformátumot követi, és üzeneteket hoz létre és értelmez, interoperabilis más kompatibilis eszközökkel.
AMQP magösszetétele
Producer
Gyártási hírek.
ConnectionFactory
Az a gyár, amely a Connection-t gyártja.
Kapcsolat
Kapcsolat, alkalmazáshálózati kapcsolat Broker TCP/IP/Triple Handshake és Quad Wave segítségével.
Az AMQP csatlakozások általában hosszú kapcsolatok. Az AMQP egy alkalmazási réteg protokoll, amely a TCP-t használja a megbízható kézbesítés érdekében. Az AMQP hitelesítési mechanizmusokat használ, és TLS (SSL) védelmet nyújt. Amikor egy alkalmazásnak már nem kell csatlakoznia az AMQP proxyhoz, akkor az AMQP kapcsolatot nemesen kell kiengednie, ahelyett, hogy egyszerűen leállítaná a TCP kapcsolatot.
Csatorna
A hálózati csatorna egy könnyű kapcsolat, amely a Kapcsolat fölé épül. Szinte minden műveletet a csatornákban végzik, amelyek üzenetek olvasására és írására szolgáló csatornák, és az ügyfelek párokat hozhatnak létre minden csatornához, amelyek mindegyike egy session feladatot jelent.
Ha a Kapcsolatot egy optikai szálas kábelhez hasonlítjuk, akkor a Csatorna csatornát az egyik optikai kábel szálszálához hasonlítjuk. Bármilyen számú csatorna létrehozható egy Connectionen.
Üzleti műveleteink többsége a csatorna felületén történik, többek között:
- queueDeclare
- A csere Deklarare a kapcsoló számára
- queueBind queueBind
- Tüntesd közzé az üzenetet alapKözzététel
- Fogyasztói híralapokFogyasztás, stb.
Alkusz
Fogadd el az ügyfél kapcsolatát AMQP entitásszolgáltatások, például rabbitmq megvalósításához.
VirtualHost (Web Hosting)
A virtuális hoszting, amelyet logikai izolációra használnak, egy virtuális hostnak több csere és sora lehet, és ugyanaz a virtuális hostnak nem lehetnek azonos nevű csereprogramjai.
Ahhoz, hogy több elszigetelt környezetet (felhasználók, felhasználói csoportok, kapcsolók, sorok stb.) egyetlen proxyn valósítson meg, az AMQP biztosítja a virtuális hosztok (virtuális hosztok - vhostok) fogalmát. Ez nagyon hasonlít a webszerverek webtárhely koncepciójához, amely teljesen elszigetelt környezetet biztosít az AMQP entitások számára. Amikor a kapcsolat létrejött, az AMQP kliens megadja, melyik virtuális hostot használja.
Tőzsde
A switch üzeneteket fogad el, és üzeneteket küld a kötött sorba az útvonalkulcs alapján (üzenettárolási képesség nélkül).
A switch egy AMQP entitás, amelyet üzenetek küldésére használnak. Miután a switch üzenetet kap, egy vagy nulla sorba irányítja. Az általa használt útvonal-algoritmust a kapcsoló típusa és a kötési szabályok határozzák meg.
Kapcsolótípus:
- Közvetlen csere
- Fanout csere
- Témacsere
- Fejléccsere
Kapcsoló tulajdonságai:
- Név: A kapcsoló neve
- Tartósság: Egy kitartási zászló, amely jelzi, hogy ez a kapcsoló tartós-e vagy sem
- Automatikus törlés: Törlés zászla, ami jelziAmikor minden sorba ezzel a csere véget ért, hogy töröljük-e őket
- Érvek: Magától az ügynöktől függenek
Kapcsoló állapota:
A bróker újraindítása után is léteznek állandó kapcsolók, míg a staging switchek nem, (ezeket újra be kell jelenteni, miután a bróker újra online lett).
Alapértelmezett kapcsoló
Az alapértelmezett csere valójában egy közvetlen csere, amelyet az üzenetközvetítő előre bejelent, és amelynek nincs neve (a név üres lánc).
Az alapértelmezett kapcsolót úgy is elképzelheted, mint egy különleges, közvetlenül csatlakoztatott kapcsolót.
Alapértelmezett kapcsoló neve: Null string (AMQP alapértelmezett)
Alapértelmezett kapcsolótípus: Közvetlenül csatlakoztatott kapcsoló
Sor létrehozásakor, amennyiben a kötendő kapcsoló nincs megadva, automatikusan az alapértelmezett kapcsolóhoz lesz kötve, és a kötés útvonalkulcs neve megegyezik a sornévével.
Közvetlen csatlakozás a kapcsolóhoz
Egy közvetlenül csatolt kapcsoló az üzenet által hordozott útvonalkulcs alapján továbbítja az üzeneteket a megfelelő kötőkulcsok sorához. Az egysugárzású útvonal, amelyet a közvetlen kapcsoló használ az üzenet kezelésére.
Sor létrehozásakor, ha közvetlen kapcsolóhoz van kötve, nem kell megadnia az útvonalkulcs nevét, mert alapértelmezett útvonalkulcs neve lesz, amely megegyezik a sor névével.
Egy közvetlenül csatlakoztatott kapcsolók sorában általában több felhasználó között osztják el a feladatokat egy cikluson belül (ezt nevezzük pollingnak).
Munkafolyamat:
- Amikor egy sort kapcsolóhoz kötöd, adj neki egy kötési kulcsot, feltételezve az R-t;
- Amikor egy üzenetet Routing Key-vel küldenek egy közvetlenül csatlakoztatott switchre, a switch egy sorba vezeti egy Routing Key-vel.
Ventilátorkapcsolók
A ventilátorkapcsoló minden hozzá kötött sorhoz irányítja az üzeneteket, függetlenül a kötött útvonalkulcstól.
Ha N sor van kötve egy szektorkapcsolóhoz, akkor amikor üzenetet küldenek erre a szektorkapcsolóra, a kapcsoló külön-külön küldi az üzenet másolatát minden N sornak. A ventilátorkapcsolókat általában a sugárzott üzenetek továbbítására használják.
Alkalmazási forgatókönyvek:
üzenetek sugárzása;
Csoportos csevegés funkció.
Témaváltás
A témaváltás üzeneteket küld egy vagy több sorba az útvonalkulcs és az Exchange típusa szerint, és gyakran használjuk különféle publish/subscribe, azaz előfizetések közzétételére is.
A közvetlenül csatlakoztatott kapcsolók útvonalválasztási szabályai szigorúan egyeznek, ami azt jelenti, hogy az útvonalkulcsnak egyeznie kell a Kötési Kulmával, mielőtt üzenetet küldene a sorba.
A témaváltás útvonali szabályai homályos meccsek, amelyeket úgy lehet elérni, hogy néhány szabályt wildcard-okkal teljesítenek.
A törvény kimondja:
- A kötési kulcsban két különleges karakter is lehet * és # a homályos párosításhoz. ahol * egy szóhoz kapcsolódik, #用于匹配多个单词 (lehet nulla)
- Az útvonalkulcs egy ponttal elválasztott láncszál (minden egyes ponttal elválasztott stringet jelölünk egy szónak)
- Amikor a producer elküldi az Routing Key=A.A.A üzenetet, csak az A.*.* elégedett meg, és csak a 1. sorba kerül.
- Amikor a producer elküldi az Routing Key=A.B.A üzenetet, az A.*.* és *.B.* kielégítése az 1. és 2. sorba kerül.
- Amikor a producer elküldi az Útvonalkulcs=A.B.C üzenetet, akkor A.*.*, *.B.* és *.* teljesülnek. C a 1-es sorba, 2-sor és 3-as sorba van irányítva.
Alkalmazási forgatókönyvek:
- kategóriákat vagy címkéket érintő hírfrissítések;
- Háttérfeladatok, amelyeket több dolgozó végz, akik mindegyike felelős bizonyos feladatok kezeléséért.
Fejkapcsoló
A fejléckapcsolók nem a router kulcs egyezési szabályaira támaszkodnak az üzenetek összekötéséhez szükséges kulcsokhoz, hanem a küldött üzenet tartalmában szereplő fejlécek attribútuma alapján egyeznek.
A fejkapcsolók egy másik közvetlenül csatlakoztatott kapcsoló megnyilvánulásaként tekinthetők. Azonban egy közvetlen kapcsoló útvonalkulcsának stringnek kell lennie, és a fejléc attribútumértékei nem korlátozódnak ezzel, akár egész számok, hash értékek (szótárok) is lehetnek. Nagyobb rugalmasság (de a gyakorlatban ritkán használunk fejkapcsolókat).
Munkafolyamat:
- Amikor egy sorba egy fejléckapcsolóhoz van kötve, több fejléc is egyszerre van kötve az egyeztetéshez.
- A bejövő üzenetek fejlécet és egy "x-match" paramétert viselnek. Ha az "x-match" "any"-ra van állítva, a fejléc bármely értéke összeegyeztethető, és ha az "x-match" "all"-ra van állítva, akkor a fejléc összes értékét össze kell egyeztetni.
Switch összefoglaló
Kötés
Virtuális kapcsolat a Exchange és Queue között.
A BindingKey egy szabályleírás az Exchange és Queue kötelékekhez. A kötési kulcs megadja, hogy milyen típusú Útválasztási Kulcsot rendelnek hozzá a jelenleg kötött Sorhoz a jelenlegi csere alatt.
Útvonalkulcs
Útválasztási szabályok, amelyeket a virtuális gép használhat arra, hogy meghatározza, hogyan lehet egy adott üzenetet irányítani.
Kötőkulcs vs. Útvonalkulcs
- A kötési kulcs a sor és a kapcsoló közötti kulcs;
- Az Útvonalkulcs egy információ, amelyet a gyártó küld a kapcsolónak;
- Amikor a Binding Key és a Routing Key megfelelőek, helyezze az üzenetet a megfelelő sorba.
A Binding Key az Exchange és Queue kötés szabályleírása, amelyet arra használnak, hogy elemzzék, amikor a Exchange üzenetet kap, az Exchange által kapott üzenetnek lesz egy Útvonalválasztási kulcsmező, és az Exchange ezt az útvonalkulcsot az aktuális Exchange összes kötési kulcsával párosítja, és ha a követelmények teljesülnek, azt a Binding felé küldik A kulcs a sorhoz van kötve az üzenet elküldéséhez.
Kulcs kötése vs. Router billentyű különböző kapcsolókban
Alapértelmezett kapcsoló: A Binding Key a Queue neve, amely nem testreszabható. Az Útvonalkulcs egyben a sornév is, mielőtt sikeresen továbbítható lenne a sorba
Közvetlen kapcsoló: A Binding Key a Queue neve, amely testreszabható. Az útvonalkulcsokat csak akkor lehet sikeresen továbbítani a sorhoz, ha a Binding Key ugyanaz
Ventilátorkapcsoló: Nincs kötőkulcs; Természetesen nincs Router Kulcs. Automatikusan irányítva minden kapcsolóhoz kötött sorhoz
Témakapcsoló: egyedi Binding Key; Testreszabni a Router Key-t. Útvonalkulcs==Kötési kulcs, és a fuzzy egyezést sikeresen kell továbbítani a sorba
Fejkapcsoló: nincs kötőkulcs; Természetesen nincs Router Kulcs. Egyezések az üzenet tartalmában szereplő fejlécek attribútumán alapulnak
Sor
Tárolja azokat az üzeneteket, amelyeket az alkalmazás hamarosan fogyasztanak.
Sor tulajdonságok:
- Név: A sor neve
- Tartós: A sor még mindig létezik, miután újraindították az üzenetközvetítőt.
- Exkluzív: Csak egy kapcsolat használja, és a sorba törlik, amikor a kapcsolat lezáródik
- Automatikus törlés: Törölve, amikor az utolsó fogyasztó lemond előiratkozásról
- Érvek: Néhány üzenetközvetítő extra funkciókhoz használja, hasonlóan a TTL-hez
Sor létrehozása:
A sorok csak a bevallásuk után használhatók. Ha még nincs sor a sor, a sorban való bejelentés létrehozza azt. Ha a deklarált sor már létezik, és az attribútumok azonosak, a deklaráció nem befolyásolja az eredeti sort. Ha a deklarációban szereplő attribútumok eltérnek a meglévő sorban lévőektől, akkor csatornaszintű kivétel kerül létre 406-os hibakóddal.
Queue tartósság:
A tartóssági sor a lemezen tárolódik, és ott marad, amikor a bróker újraindítja. Azokat a sorokat, amelyek nem maradnak fenn, átmeneti soroknak nevezik. Nem minden forgatókönyv és eset igényel sorban tartást.
Egy tartós sor nem teszi az oda irányított üzeneteket állandóvá. Ha az üzenetügynök leáll és újraindítják, a tartóssági sor újra bejelenthető az újraindítás során, és mindenképpen csak a megőrzött üzenetek állíthatók vissza.
Fogyasztó
Fogyasztói fogyasztási hírek. Az AMQP-ben kétféleképpen kaphatják meg a fogyasztók a függőben lévő üzeneteket:
Üzenetközmű továbbítja az üzeneteket a fogyasztókhoz (push API)
A fogyasztók aktívan kapnak üzeneteket (pull API)
Megjegyzés: Ha több fogyasztó ugyanazt a sorba hallgatja, a sorban lévő üzeneteket csak az egyik fogyasztó fogja fogyasztani (nem egyszer minden fogyasztó számára)
Üzenet
Az üzenetek, szolgáltatások és alkalmazások között továbbított adatok Tulajdonságokból és testekből állnak.
Az attribútumok módosítják az üzeneteket, például az üzenetprioritást, késleltetést és egyéb fejlett funkciókat, és a fő test az üzenet törzsének tartalma.
Üzenet tulajdonságai:
- Tartalomtípus
- Tartalomkódolás
- Útvonalkulcs
- Szállítási mód (tartós vagy sem)
- Szállítási mód (tartós vagy nem tartós)
- Üzenetprioritás
- Üzenetküldési időbélyeg
- Lejárati idő
- Publisher application id
Üzenet teste:
Az attribútumok mellett az AMQP üzenetek tartalmaznak egy hasznos terhet is (az üzenet által valójában hordozott adatot), amelyet az AMQP proxy átlátszott, bájtokból álló tömbként kezel.
Az üzenetközvetítő nem vizsgálja és nem módosítja a hasznos terhet. Az üzenetek csak attribútumokat tartalmazhatnak anélkül, hogy nem hordoznak hasznos terhet. Általában soros formátumban használ adatokat, mint a JSON, és a pénzmegtakarítás érdekében a protokoll pufferek és MessagePackek szeresítik a strukturált adatokat üzenetek hasznos rakományként történő közzétételéhez. Az AMQP és társai általában a "tartalomtípus" és a "tartalomkódolás" mezőket használják az üzenetekkel való kommunikációra a hasznos terhek azonosítására, de ez csak konvenciókon alapul.
Üzenetkitartás:
Az üzenetek tartósan jelennek meg, és az AMQP ügynök ezt az üzenetet a lemezen tárolja. Ha a szervert újraindítják, a rendszer megerősíti, hogy a kapott tartóssági üzenet nem veszett el.
Egyszerűen egy üzenet küldése egy állandó switchhez vagy egy tartós sorba való irányítása nem teszi az üzenetet tartósá: az üzenet tartóssága teljes mértékben az üzenet állandósági módjától függ.
Az üzenetek tartós közzététele teljesítménykárosodást okozhat.
AMQP munkafolyamata
A Kiadó üzenetet közöl a Csere segítségével.
A switch a bejövő üzeneteket a kapcsolóhoz kötött sorba osztja el az útvonali szabályok szerint.
Végül az AMQP ügynök továbbítja az üzenetet a fogyasztónak, aki feliratkozott erre a sorra, vagy a fogyasztó maga kapja meg, ha szükséges.
AMQP üzenetküldési mechanizmus
Üzenet megerősítése
A fogyasztók időnként nem dolgozzák fel az üzeneteket, vagy néha közvetlenül összeomlanak. A hálózati okok is különféle problémákat okozhatnak.
Ez felveti a kérdést, mikor van a megfelelő időpont az AMQP ügynököknek az üzenetek törlésére.
Az AMQP két üzenet-visszaigazolási módja:
Automatikus megerősítés mód: Töröld az üzenetet azkor, amint az üzenet közmű elküldi a fogyasztónak. (Az AMQP módszerrel együtt: basic.deliver vagy basic.get-ok)
Explicit megerősítő mód: Várd meg, amíg a fogyasztó visszaigazolást küld, mielőtt törölnéd az üzenetet. (AMQP módszerrel: basic.ack)
Ha egy fogyasztó leteszi a telefont anélkül, hogy visszaigazoló nyugtát küld, az AMQP ügynöke visszaadja az üzenetet egy másik fogyasztónak. Ha ekkor nincs elérhető fogyasztó, az üzenetközvetítő megvárja, hogy a következő fogyasztó regisztráljon ebben a sorban, majd újra megpróbálja kézbesíteni.
Üzenetek elutasítása
Amikor egy fogyasztó üzenetet kap, a feldolgozási folyamat sikeres vagy kudarcot vallhat. A fogyasztó jelezheti az üzenetközvetítőnek (üzenetközmű), hogy az üzenetet nem dolgozták fel (vagy ekkor nem fejezték be) egy "elutasított üzenet" miatt.
Ha egy üzenetet elutasítanak, a fogyasztó megmondhatja az üzenetközvetítőnek, mit tegyen vele – megsemmisítse vagy visszategye a sorba.
Ha csak egy fogyasztó van ebben a sorban, ügyelj rá, hogy ne utasítsd el az üzenetet, és ne tedd vissza a sorba, ami miatt az üzenet végtelenül ugyanazon a felhasználónál fut vissza.
Az AMQP-ben a basic.reject módszert használják az üzenetek elutasításának végrehajtására. Azonban a basic.reject fájlnak van egy korláta: nem lehet vele több üzenetet visszautasítani visszaigazolással. De ha RabbitMQ-t használsz, használhatod az AMQP 0-9-1 kiterjesztést, az úgynevezett negatív igazolásokat (más néven nacks), hogy megoldd ezt a problémát.
Eredeti:A hiperlink bejelentkezés látható.
|
Közzétéve 2022. 08. 14. 23:22:55
|
|
|
|
