Az AMQP (Advanced Message Queuing Protocol) egy nyílt alkalmazási réteg protokoll az üzenetek rendszerösszetevők közötti továbbítására. A fő gondolat az, hogy az egyes alrendszerek (vagy független alkalmazások) tetszőlegesen cserélhetnek üzeneteket egy AMQP-brókeren keresztül, amely útválasztást végez , esetleg garantálja az adatfolyamok kézbesítését, elosztását, előfizetést a kívánt típusú üzenetekre.
A protokoll architektúrát John O'Hara, a JP Morgan Chase & Co [1] fejlesztette ki .
Az AMQP három koncepción alapul:
A protokoll két rétegre osztható:
Várólista példák:
A protokoll nem korlátozódik erre a három típusra. Ezeket példaként adjuk meg.
Üzeneteket fogad a szolgáltatótól, és előre meghatározott feltételek szerint továbbítja az üzenetsorba. Az ilyen kritériumokat kötéseknek nevezzük. Az Exchange egy üzenetegyeztető és -útválasztó mechanizmus. Az üzenetek és azok paraméterei (kötései) alapján döntenek a sorba vagy másik központba való átirányításról. Ne tároljon üzeneteket.
A csere kifejezés algoritmust és algoritmuspéldányt jelent. Azt is mondják, hogy a csere típusa és a cserepéldány.
Az AMQP szabványos cseretípusok készletét határozza meg. Az alkalmazások létrehozhatják saját cserepéldányukat.
Minden központ saját útválasztási algoritmust valósít meg. A szabvány Funkcionális specifikációjában több szabványos cseretípus található. Ezek közül kettő a fontos:
A szerver több cserét hoz létre, beleértve a közvetlen és a témát. Jól ismert nevük lesz, és kliens alkalmazások is tudnak majd dolgozni velük.
Minden AMQP-kiszolgáló több cserepéldányt hoz létre előre. Ezek a példányok akkor léteznek, amikor a kiszolgáló fut, és nem semmisíthetők meg. Az AMQP alkalmazások saját központokat is létrehozhatnak. Az AMQP erre nem használja a create metódust, hanem a példány deklarálása történik meg, ami a következő logikát követi: "létrehoz, ha nem jött létre, akkor folytassa másként". Elmondható, hogy a csere létrehozása idempotens . Valószínűleg az alkalmazások szükség szerint cseréket hoznak létre, majd szükségtelenként megsemmisítik azokat. Az AMQP módszert biztosít a csere megsemmisítésére.
Általánosságban elmondható, hogy a központ megvizsgálja az üzenet tulajdonságait, a fejlécmezőket és a törzs tartalmát, és ezek és esetleg más forrásból származó adatok felhasználásával dönti el, hogyan továbbítsa az üzenetet. A legtöbb egyszerű esetben az Exchange egy kulcsmezőt vesz figyelembe, amelyet Routing Key -nek nevezünk . Az útválasztási kulcs egy virtuális cím, amelyet a csereszerver használhat annak eldöntésére, hogy küldjön-e üzenetet. Pont-pont útválasztásnál az útválasztási kulcs általában az üzenetsor neve. Pub-sub- routing esetén az útválasztási kulcs általában a témahierarchia értéke (téma - lásd: kiadvány/előfizetés). Bonyolultabb esetekben az útválasztási kulcs kombinálható az üzenetfejléc-mezők és/vagy az üzenettartalom szerinti útválasztással.
Amikor egy ügyfélalkalmazás üzenetsort hoz létre, a következő tulajdonságokat adhatja meg:
Az AMQP-üzenet tulajdonságok és nem nyilvános tartalom halmazából áll. A gyártó új üzenetet hoz létre az AMQP ügyfél API használatával. A gyártó tartalmat ad az üzenethez, és esetleg beállít néhány üzenettulajdonságot. A gyártó az üzenetet útválasztási információval jelöli meg, amely címnek tűnik, de bármi lehet. A producer ezután elküldi az üzenetet a cserére . Amikor egy üzenet megérkezik a kiszolgálóhoz, az Exchange (általában) a kiszolgálón is létező várólistákhoz irányítja azt. Ha az üzenet nem irányítható, az Exchange eldobhatja vagy visszaküldheti az alkalmazásnak. A producer dönti el, hogyan kezelje a nem irányítható üzeneteket.
Egy üzenet több üzenetsorban is létezhet. A szerver ezt különböző módokon tudja kezelni, például az üzenetet referenciaszámlálással másolja, stb. Ez nem befolyásolja az együttműködést. Ha azonban egy üzenetet több üzenetsorba irányítanak át, az minden üzenetsorban azonos. Itt nincs egyedi azonosító a különböző másolatok megkülönböztetésére.
Amikor egy üzenet megérkezik az üzenetsorba, azonnal megkísérli eljuttatni a fogyasztóhoz az AMQP-n keresztül. Ha ez nem lehetséges, akkor az üzenet az üzenetsorba kerül (a gyártó kérésére a memóriában vagy a lemezen ), és várja, hogy a fogyasztó készen álljon. Ha nincs fogyasztó , akkor a sor üzenetet küldhet a gyártónak AMQP-n keresztül (ismét, ha a gyártó kérte).
Amikor az üzenetsor üzenetet tud küldeni a fogyasztónak , eltávolítja az üzenetet a belső tárhelyéről. Ez történhet azonnal, vagy azután, hogy a fogyasztó elismeri, hogy sikeresen elvégezte a munkáját, feldolgozta az üzenetet. A fogyasztó dönti el, hogy az üzeneteket hogyan és mikor „nyugtázzák”. a fogyasztó vissza is utasíthatja az üzenetet (negatív visszaigazolás).
A termelői üzenetek és a fogyasztói elismervények tranzakciókba vannak csoportosítva. Amikor egy alkalmazás mindkét szerepet betölti, ami gyakran előfordul, vegyes munkát végez: üzeneteket és visszaigazolásokat küld, majd véglegesíti vagy visszavonja a tranzakciót.
Az üzenetek eljuttatása a szervertől a fogyasztóhoz nem tranzakciós jellegű.
A Producer egy ügyfélalkalmazás, amely üzeneteket tesz közzé cserére .
Az e-mail eszközhöz hasonlóan láthatja, hogy a gyártó nem küld üzeneteket közvetlenül a sorba (üzenetsorba). Minden más viselkedés megtörné az absztrakciót az AMQ modellben. Ez hasonló lenne egy e-mail üzenet életciklusához: az e-mail feloldása, az MTA útválasztási tábláinak megkerülése és közvetlenül a postafiók elérése. Ez lehetetlenné tenné a közbenső szűrés és feldolgozás, például a spamészlelés beiktatását.
Az AMQ modell ugyanazt az elvet használja, mint az e-mail rendszer: az összes üzenetet egyetlen központnak vagy MTA-nak küldik el , amely a feladó elől rejtett szabályok és információk alapján ellenőrzi az üzeneteket, és olyan terjesztési pontokra irányítja őket, amelyek szintén rejtve vannak a küldő elől. feladó. (és a feladó elől is rejtett leadási pontokra irányítja őket - itt a terjesztési pontok a dokumentációból származó leadási pontok).
A fogyasztó az az ügyfélalkalmazás, amely üzeneteket fogad az üzenetsorból.
E-mail analógiánk kezd tönkremenni, ha a fogyasztót (címzetteket) nézzük . Az e-mail kliensek passzívak – el tudják olvasni a postafiókokat, de nincs hatással a postafiókok feltöltésére. Az AMQP segítségével a fogyasztó passzív is lehet, akárcsak az e-mail kliensek. Vagyis írhatunk olyan alkalmazást, amely egy adott üzenetsorra figyel, és egyszerűen feldolgozza a beérkező információkat. Ebben az esetben az üzenetsornak készen kell állnia az alkalmazás indítása előtt, és hozzá kell „csatolni”.
A fogyasztó a következő tulajdonságokkal is rendelkezik:
Olyan ez, mint egy levelezőrendszer, amely protokoll szinten képes:
A legtöbb integrációs architektúrának nincs szüksége ilyen szintű bonyolultságra. A legtöbb AMQP-felhasználónak szüksége van az alapfunkciókra a dobozból. Az AMQP ezt a következő módon biztosítja:
Ennek eredményeként a mögöttes összerendelés lehetővé teszi a gyártó számára, hogy üzeneteket küldjön közvetlenül az üzenetsorba, így emulálja a legegyszerűbb sémát az üzenet vevőnek történő elküldésére, amelyet az emberek egy hagyományos köztes szoftvertől várnának.
Az alapösszerendelés nem akadályozza meg az üzenetsor használatát összetettebb tervekben. Lehetővé teszi az AMQP használatát a kötési és cseremechanizmusok konkrét ismerete nélkül.
A szakasz az alkalmazás és a szerver közötti interakció folyamatát írja le
A köztes szoftverek összetettek, és a protokollstruktúra kialakításakor a készítői igyekeztek megszelídíteni ezt a bonyolultságot. Megközelítésük az volt, hogy egy hagyományos API-t modelleztek olyan osztályokon, amelyek metódusokat tartalmaznak, és mindegyik metódus pontosan egy dolgot csinál, és jól csinálja. Ez rengeteg parancsot eredményez, de viszonylag könnyen érthető.
Az AMQP parancsok osztályokba vannak csoportosítva. Minden osztály egy meghatározott funkcionális területet fed le. Egyes osztályok nem kötelezőek – minden társ megvalósítja azokat az osztályokat, amelyeket támogatnia kell.
Két különböző párbeszéd módszer létezik:
A metódusfeldolgozás egyszerűsítése érdekében minden szinkron kéréshez külön választ adunk meg. Vagyis egy módszert nem használnak két különböző kérés megválaszolására. Ez azt jelenti, hogy a partner szinkron kérés küldésekor elfogadhatja és feldolgozhatja a bejövő metódusokat, amíg az egyik érvényes szinkron válasz meg nem érkezik. Ez különbözteti meg az AMQP-t a hagyományosabb RPC protokolloktól.
A metódus formálisan szinkron kérés, szinkron válasz (egy adott kérésre) vagy aszinkron. Végül minden metódus formálisan kliensoldaliként (azaz szerver-kliensként) vagy szerveroldaliként (kliens-szerverként) van meghatározva.
Az AMQP-t úgy tervezték, hogy összehasonlítható legyen a köztes szoftver API-val. A párosítási folyamat némileg intellektuális, i.e. megérti, hogy nem minden módszer és nem minden érv értelmes az alkalmazáshoz, hanem mechanikus is, pl. bizonyos szabályok felállításával manuális beavatkozás nélkül minden módszer összeilleszthető.
Ennek az az előnye, hogy az AMQP szemantikáját megtanulva a fejlesztők ugyanazt a szemantikát találják meg bármilyen keretrendszerben is.
Példa a Queue.Declare metódusra:
Várólista . kijelent sor = az én . sorban auto - delete = IGAZ kizárólagos = HAMISHálózati keretté alakítható:
+--------+----------+----------+------------+-------- ----+ | Sor | kijelenteni | az én . sor | 1 | 0 | +--------+----------+----------+------------+-------- ----+ osztály metódus neve auto - kizárólagos törlésVagy magas szintű API-módszerben
Várólista . Declare ( "my.queue" , TRUE , FALSE );Aszinkron metódusillesztő logika pszeudokódban:
küldési mód a szervernekSzinkron metódus illesztő logika pszeudokódban:
kérési mód küldése a szervernek ismétlés várja meg a szerver válaszát ha a válasz aszinkron módszer _ folyamatmódszer ( általában szállított vagy visszaküldött tartalom ) _ _ más állítsa , hogy a metódus érvényes válasz a kérésre kilépés ismétlés vége – ha vége - ismételje megÉrdemes megjegyezni, hogy a legtöbb alkalmazás esetében a köztes szoftver teljesen elrejthető a rendszer technikai rétegeiben, és a ténylegesen használt API kevésbé fontos, mint az, hogy a köztes szoftver robusztus és működőképes legyen.
A chatty protokoll lassú. Aktívan használjuk az aszinkront olyan esetekben, amikor teljesítményprobléma van. Általában itt küldünk tartalmat egyik társról a másikra. A módszereket a lehető leggyorsabban szállítjuk, anélkül, hogy megvárnánk a visszaigazolásokat. Ahol szükséges, magasabb szinten, például fogyasztói szinten megvalósítjuk az ablakozást és a szabályozást .
A protokoll mellőzi az értesítéseket, mert érvényesítési modellt valósít meg minden eseményre. Vagy sikerül, vagy kivételt dobnak? amely bezár egy csatornát vagy kapcsolatot.
Az AMQP-ben nincsenek értesítések. A sikeres esemény - csendben, kudarc - kijelenti magát. Ha egy alkalmazásnak a sikerek és a kudarcok kifejezett nyomon követésére van szüksége, akkor tranzakciókat kell használnia.
A csatlakozást úgy tervezték, hogy tartós legyen és sok csatornát kezeljen.
Kapcsolat életciklusaA nem teljesen megnyitott kapcsolatok hibáira vonatkozó információcsere nem történik meg. A hibát észlelő gazdagépnek további értesítés nélkül be kell zárnia a socketet.
Az AMQP egy többcsatornás protokoll. A csatornák lehetővé teszik a nehéz TCP/IP-kapcsolatok több könnyű kapcsolattá történő multiplexelését. Ez "tűzfalbarátabbá" teszi a protokollt, mivel a porthasználat kiszámítható. Ez azt is jelenti, hogy a forgalom alakítása és egyéb hálózati QoS szolgáltatások könnyen használhatók.
A csatornák függetlenek egymástól, és más csatornákkal egyidejűleg különböző funkciókat is elláthatnak, miközben a rendelkezésre álló sávszélesség fel van osztva az egyidejű feladatok között.
Elvárható és bátorított, hogy a többszálú kliens alkalmazások gyakran használják a "csatorna per-szál" modellt a fejlesztés megkönnyítése érdekében. Mindazonáltal, több kapcsolat megnyitása egy vagy több AMQP szerverrel egyetlen kliensről is teljesen elfogadható. Egy csatorna életciklusa a következő:
Lehetővé teszi egy alkalmazás számára a cserepéldányok kezelését a kiszolgálón. Ez az osztály lehetővé teszi az alkalmazás számára, hogy saját üzenetkezelő szkriptet írjon anélkül, hogy bármilyen konfigurációra támaszkodna.
Megjegyzés: A legtöbb alkalmazásnak nincs szüksége ilyen szintű bonyolultságra, és a régi köztes szoftver valószínűleg nem támogatja ezt a szemantikát.
Csere életciklusaA sorosztály lehetővé teszi az alkalmazások számára, hogy üzenetsorokat kezeljenek a kiszolgálón. Ez szinte minden üzenetet fogadó alkalmazás alapvető lépése, legalábbis annak ellenőrzésére, hogy a várt üzenetsor valóban létezik-e.
A protokoll két sor-életciklust biztosít:
Az AMQP a témakör-előfizetési mechanizmust üzenetsorok formájában valósítja meg. Ez érdekes struktúrákat tesz lehetővé, ahol az előfizetés terheléselosztható az együttműködő előfizetői alkalmazások készletében.
Előfizetés életciklusaAz alaposztály az ebben a specifikációban leírt üzenetküldési képességeket valósítja meg. A következő szemantikát támogatja:
Az AMQP kétféle tranzakciót támogat:
A Tranzakció („tx”) osztály hozzáférést biztosít az alkalmazásoknak a második típusú tranzakciókhoz, a helyi szerver tranzakciókhoz. Az osztály szemantikája a következő:
A tranzakciók a tartalom közzétételére és megerősítésére vonatkoznak, nem pedig a kézbesítésre. Ezért a visszaállítás nem állítja újra a sorba, és nem váltja ki az újrakézbesítést. Az ügyfél a következő tranzakció során nyugtázhatja ezeket az üzeneteket.
Ez a rész elmagyarázza, hogyan képezik le a parancsokat a vezetékes szintű protokollhoz.
Az AMQP egy bináris protokoll. Az információk különféle típusú keretekbe vannak rendezve. A keretek protokollmódszereket és egyéb információkat tartalmaznak. Minden képkocka ugyanazzal az általános formátummal rendelkezik: keretfejléc, hasznos terhelés és keret vége. A keret hasznos formátuma a keret típusától függ.
Szállítási szinten a TCP / IP verem vagy analógok használata feltételezhető.
Egyetlen socket kapcsolaton belül több független vezérlési folyamat is létezhet, ezeket csatornáknak nevezzük. Minden képkocka egy csatornaszámmal van számozva. A kereteik interleave révén a különböző csatornák megosztják ezt a kapcsolatot. Bármely adott csatorna esetében a keretek szigorú sorrendben futnak le, amely protokollelemző (általában állapotgép) meghajtására használható.
A kereteket kis adattípusok, például bitek, egész számok, karakterláncok és mezőtáblák felhasználásával készítjük. A keretmezők szorosan össze vannak csomagolva anélkül, hogy lassúak vagy nehezen értelmezhetők. Protokollspecifikációk alapján viszonylag egyszerű keretező réteget mechanikusan létrehozni.
A vezetékes szintű formázást úgy tervezték, hogy méretezhető és elég sokoldalú legyen ahhoz, hogy tetszőleges magas szintű protokollokban (nem csak az AMQP-ben) használható legyen. Arra számítunk, hogy az AMQP idővel bővülni fog, javulni fog, és egyéb módon változni fog, és a vezetékes szintű formátum ezt támogatja.
A keretekben használt AMQP adattípusok:
A kliens és a szerver egyeztet egy protokollról. Ez azt jelenti, hogy amikor egy kliens csatlakozik, a szerver felkínál bizonyos opciókat, amelyeket az ügyfél elfogadhat vagy módosíthat. Ha mindketten egyetértenek az eredményben, a kapcsolat létrejöttnek minősül. A tárgyalás azért hasznos, mert lehetővé teszi a kapcsolati beállítások megadását.
A koordináció több szempontból is megvalósul:
A megállapodott korlátok mindkét fél számára lehetővé teszik a kulcspufferek előzetes kiosztását, elkerülve a holtpontot. Minden bejövő képkocka vagy engedelmeskedik a kialkudott határoknak, és ezért biztonságos, vagy túllépi azokat, ebben az esetben a másik oldal meghibásodott, és le kell tiltani. Ez nagyon jól illeszkedik az AMQP filozófiájához, miszerint "vagy úgy működik, ahogy kell, vagy egyáltalán nem működik".
Mindkét csomópont a legalacsonyabb megegyezett értékre egyezteti a határértékeket az alábbiak szerint:
TCP/IP verem - streamekkel működik, nincs beépített keretelválasztó mechanizmusa. A meglévő protokollok többféleképpen oldják meg ezt a problémát:
Minden képkocka egy fejlécből (7 oktett), egy tetszőleges méretű hasznos adatból és egy "keret vége" oktettből áll, amely észleli a hibás képkockákat:
0 1 3 7 méret + 7 méret + 8 +------+----------+-------------+ +-------------+ +--- --------+ | típus | csatorna | méret | | hasznos teher | | keret - vége | +------+----------+-------------+ +-------------+ +--- --------+ oktett rövid hosszú méret oktett oktettA keret a következőképpen olvasható:
A teljesítmény szempontjából reális megvalósításokban „előreolvasási pufferelést” vagy „olvasások összegyűjtését” használjuk, hogy elkerüljük a három külön rendszerhívást egy keret olvasásához.
A metóduskeretek magas szintű protokollparancsokat hordoznak (amelyeket "módszereknek" nevezünk). Egy metódus keret egy parancsot hordoz. A metódus keret hasznos terhelése a következő formátumú:
0 2 4 +----------+----------------------------- - - | osztály - azonosító | módszer - id | érvek ... +----------+----------------------------- - - rövid rövid ...A metódus kerete a következőképpen történik:
1. A payload metódus keretének beolvasása.
2. Kicsomagolása szerkezetbe. Ennek a módszernek mindig ugyanaz a felépítése, így gyorsan kicsomagolható
3. Ellenőrizze, hogy ez a módszer engedélyezett-e az aktuális környezetben.
4. A metódus argumentumainak érvényességének ellenőrzése.
5. Ennek a módszernek a végrehajtása.
A metódus keret törzse AMQP adatmezők (bitek, egész számok, karakterláncok és karakterlánc-táblázatok) listájaként épül fel. A rendezőkód triviálisan generálódik közvetlenül a protokoll specifikációiból, és nagyon gyors lehet.
A tartalom olyan alkalmazásadatok, amelyeket az AMQP szerveren keresztül kliensről ügyfélre továbbítunk. A tartalom durván szólva tulajdonságok halmaza, plusz az adatok bináris része. Az engedélyezett tulajdonságok halmazát az alaposztály határozza meg, és ezek alkotják a "tartalomfejléc-keretet". Az adatok tetszőleges méretűek lehetnek, és több (vagy sok) blokkra bonthatók, amelyek mindegyike egy "tartalomtest-vázat" alkot.
Ha egy adott csatorna kereteit nézzük, amint azt a vezetéken keresztül továbbítják, valami ilyesmit láthatunk:
[ módszer ] [ módszer ] [ fejléc ] [ törzs ] [ törzs [ módszer ] ...Egyes módszerek (például Basic.Publish , Basic.Deliver stb.) formálisan tartalomhordozóként vannak meghatározva. Amikor egy társ ilyen metóduskeretet küld, mindig követi azt egy tartalomfejléccel és néhány tartalomtörzs kerettel vagy anélkül. A tartalomkeret fejlécének formátuma a következő:
0 2 4 12 14 +----------+--------+-----------+----------------+ ------------- --- _ | osztály - azonosító | súly | testméret | _ ingatlan zászlók | ingatlan lista ... +----------+--------+-----------+----------------+ ------------- --- _ rövid rövid hosszú hosszú rövid maradék ...A tartalom törzsét külön keretekbe helyezzük (ahelyett, hogy egy metódusba foglalnánk), hogy az AMQP támogassa a „nulla másolat” metódusokat, ahol a tartalom soha nem kerül sorba vagy kódolásra. A tartalomtulajdonságokat saját keretükbe helyezzük, hogy a címzettek szelektíven elvehessék azokat a tartalmakat, amelyeket nem szeretnének feldolgozni.
A Heartbeat egy olyan technika, amely a TCP/IP egyik funkcióját hivatott felülbírálni, nevezetesen azt, hogy képes helyreállni egy megszakadt fizikai kapcsolat után, és csak egy meglehetősen hosszú időtúllépés után zár be. Egyes forgatókönyvekben nagyon gyorsan meg kell tudnunk, ha a társ leállt, vagy más okok miatt nem válaszol (például elakad egy hurokban). Mivel a szívverés alacsony szinten is elvégezhető, ezt egy speciális típusú keretként fogjuk megvalósítani, amely a szállítási réteg csomópontjai között cserélődik, nem pedig osztálymetódusként.
Az AMQP kivételeket használ a hibakezeléshez. Bármilyen működési hiba (nem található üzenetsor, elégtelen hozzáférési jogosultságok stb.) csatornakivételt vált ki. Bármilyen szerkezeti hiba (rossz argumentum, rossz metódussorozat stb.) kapcsolati kivételt eredményez. A kivétel bezárja a csatornát vagy a kapcsolatot, és válaszkódot és választörzset küld vissza az ügyfélalkalmazásnak. 3 számjegyű válaszkódot, valamint a HTTP-ben és sok más protokollban használt válaszszöveg-sémát használunk.
A kapcsolatról vagy csatornáról azt mondják, hogy "nyitott" a kliens számára, amikor Open üzenetet küld, és a szerver számára, amikor Open-Ok üzenetet küld. Ezentúl egy csatornát vagy kapcsolatot bezárni kívánó partnernek ezt az itt leírt handshake protokoll használatával kell megtennie.
A csatorna vagy kapcsolat bármilyen okból – normál vagy kivételes – bezárását körültekintően kell elvégezni. A hirtelen zárásokat nem mindig észleljük gyorsan, és kivétel után elveszíthetjük a hibakódokat. A helyes elrendezés az, hogy a zárást manuálisan kezdeményezzük, hogy a csatorna/kapcsolat csak akkor záruljon le, ha megbizonyosodtunk arról, hogy a másik fél is tisztában van a helyzettel.
Amikor egy partner úgy dönt, hogy bezár egy csatornát vagy kapcsolatot, elküldi a Close metódust. A fogadó csomópontnak a zárásra egy Close-Ok-val kell válaszolnia, majd mindkét fél lezárhatja a csatornáját vagy a kapcsolatát. Vegye figyelembe, hogy ha a társak figyelmen kívül hagyják a Bezárást, akkor holtpont léphet fel, ha mindkét partner egyszerre küldi el a Bezárást.
Lehetséges az AMQP keretek olvasása és írása közvetlenül az alkalmazásból, de ez rossz tervezés lenne. Még a legegyszerűbb AMQP-beszélgetés is sokkal összetettebb, mint például a HTTP, és az alkalmazásfejlesztőknek nem kell érteniük olyan dolgokat, mint például a bináris keretezési formátumok ahhoz, hogy üzenetet küldhessenek az üzenetsorba. Az ajánlott AMQP kliens architektúra több absztrakciós szintből áll:
Ezenkívül általában van bizonyos szintű I/O, ami lehet nagyon egyszerű (Szinkron foglalat olvasása és írása) vagy összetett (teljesen aszinkron többszálú I/O). Ez a diagram az általános javasolt architektúrát mutatja:
+------------------------+ | alkalmazás | +-----------+------------+ | +------------------------+ +---| API -réteg |---- Kliens API -réteg -----+ | +-----------+------------+ | | | | | +-----------------------+ +-----------------+ | | | Kapcsolatkezelő + ---- + Framing Layer | | | +-----------+------------+ +-------+ | | | | | +-----------------------+ | +---| Aszinkron I / O réteg |--------------------------+ +-----------+------------+ | ------- - - - - Hálózat - - - - -------Ebben a dokumentumban, amikor "kliens API"-ról beszélünk, az alkalmazás alatti összes réteget értjük (i/o, keretezés, kapcsolatkezelő és API rétegek. Általában két különálló dologként beszélünk az "kliens API-ról" és az "alkalmazásról". az alkalmazás az ügyfél API-t használja a köztesszoftver-kiszolgálóval való kommunikációhoz.
Az üzenet egy útválasztó és köztes szoftver-sorrendező rendszer atomi feldolgozó egysége. Az üzenetek olyan tartalmat tartalmaznak, amely egy tulajdonságkészletet tartalmazó tartalomfejlécből és egy bináris adatok átlátszatlan blokkját tartalmazó tartalomtörzsből áll.
Egy üzenet számos különböző alkalmazási entitásnak felelhet meg:
Az üzenetek állandóak lehetnek. Az állandó üzenetek biztonságosan tárolódnak a lemezen, és garantáltan kézbesítik még nagyobb hálózati leállás, szerverhiba, túlcsordulás stb. esetén is.
Az üzenetek elsőbbséget élvezhetnek. Magas prioritású üzenet kerül elküldésre, mielőtt alacsonyabb prioritású üzenetek várakoznak ugyanabban az üzenetsorban. Ha az üzeneteket el kell dobni a szolgáltatás bizonyos szintjének fenntartása érdekében, a szerver először az alacsony prioritású üzeneteket dobja el.
A szerver NEM SZABAD módosítani az általa fogadott és a fogyasztói alkalmazásoknak továbbított üzenetek tartalmi törzsét. A szerver hozzáadhat információkat a tartalomfejlécekhez, de NEM SZABAD eltávolítani vagy módosítani a meglévő információkat.
Virtuális gazdagépekA virtuális gazdagép a szerveren belüli adatok egy része, ami egy adminisztrációs kényelem, amely hasznosnak bizonyul majd azok számára, akik az AMQP-t szolgáltatásként kívánják nyújtani egy megosztott infrastruktúrán.
A virtuális gazdagép saját névteret, cseréket, üzenetsorokat és minden kapcsolódó objektumot tartalmaz. Minden kapcsolatot egy virtuális gazdagéphez kell társítani.
Az ügyfél a hitelesítés után a Connection.Open metódusban választja ki a virtuális gazdagépet. Ez azt jelenti, hogy a kiszolgáló hitelesítési sémája közös az adott kiszolgálón lévő összes virtuális csomópontban. A használt engedélyezési séma azonban minden virtuális gazdagép esetében egyedi lehet. Ez hasznos lehet egy megosztott tárhely infrastruktúrához. Azoknak a rendszergazdáknak, akik különböző hitelesítési sémákat igényelnek minden egyes virtuális gazdagéphez, külön kiszolgálókat kell használniuk
A kapcsolaton belüli összes csatorna ugyanazzal a virtuális gazdagéppel működik. Nincs mód arra, hogy ugyanazon a kapcsolaton egy másik virtuális gazdagépre lépjen kapcsolatba, és nincs mód másik virtuális gazdagépre váltani a kapcsolat megszakítása és újrakezdés nélkül.
A protokoll nem kínál semmilyen mechanizmust a virtuális gazdagépek létrehozására vagy konfigurálására – ez a szerveren belül nem meghatározott módon történik, és teljes mértékben megvalósításfüggő.
CserékAz Exchange egy üzenet-útválasztó ügynök egy virtuális gazdagépen belül. A cserepéldány (amelyre általában "csereként" hivatkozunk) üzeneteket és útválasztási információkat – elsősorban az útválasztási kulcsot – fogad, és vagy továbbítja az üzeneteket üzenetsoroknak vagy belső szolgáltatásoknak. A központok elnevezése virtuális gazdagépenként történik.
Az alkalmazások szabadon hozhatnak létre, oszthatnak meg és semmisíthetnek meg cserepéldányokat saját hatáskörükön belül.
A cserék lehetnek véglegesek, ideiglenesek vagy automatikusan törölhetők. Az állandó cserék mindaddig léteznek, amíg el nem távolítják őket. Ideiglenes cserék léteznek a szerver leállításáig. Az automatikusan törölt cserék mindaddig léteznek, amíg a továbbiakban nem használják őket.
A szerver a cseretípusok meghatározott készletét biztosítja. Minden cseretípus egy adott leképezést és algoritmust valósít meg, a következő részben meghatározottak szerint. Az AMQP néhány cseretípust ír elő, és néhány további típust ajánl. Ezen túlmenően minden kiszolgáló implementáció saját cseretípusokat adhat hozzá.
Egy központ egyetlen üzenetet párhuzamosan több üzenetsorba irányíthat. Ez több üzenetpéldányt hoz létre, amelyek egymástól függetlenül kerülnek felhasználásra.
A közvetlen cseretípusA közvetlen csere típusa így működik:
A kiszolgálónak közvetlen cserét KELL megvalósítania, és minden virtuális gazdagépen előre KELL definiálnia legalább két közvetlen cserét: egy amqp.direct nevű és egy nyilvános név nélkülit , amely a nyilvános metódusok kezelésének alapértelmezett cseréjeként szolgál.
Vegye figyelembe, hogy az üzenetsorokkal bármely érvényes útválasztási kulcs értékével kapcsolatba léphet, de leggyakrabban az üzenetsorokkal a saját nevükkel, mint útválasztási kulcs használatával lép kapcsolatba.
Mindenekelőtt az összes üzenetsort automatikusan egy nyilvános név nélküli adatcseréhez KELL kötni, az üzenetsor nevét használva útválasztási kulcsként.
A Fanout Exchange típusA Fanout Exchange így működik:
A Fanout Exchange tervezése és megvalósítása triviális. Ez a típusú csere és az előre meghatározott amq.fanout név szükséges .
A témacsere típusaA témacsere a következőképpen működik:
A témacseréhez használt útválasztó kulcsnak pontokkal elválasztott szavakból kell állnia. A szó minimális mérete 0 karakter. Minden szó tartalmazhat AZ és az betűket, valamint 0-9 számokat.
Az útválasztási minta ugyanazokat a szabályokat követi, mint az útválasztási kulcs, azzal a kiegészítéssel, hogy a * egy szónak felel meg, a # pedig nulla vagy több szónak felel meg. Így a *.stock.# útválasztási séma megegyezik az usd.stock és eur.stock.db útválasztási kulcsokkal, de nem a stock.nasdaq-val.
A Topic Exchange egyik javasolt sémája az összes ismert útválasztási kulcs készletének megtartása és frissítése, amikor a kiadók új útválasztási kulcsokat használnak. Megadhatja az összes kötést egy adott útválasztási kulcshoz, és így gyorsan megtalálhatja az üzenetek üzenetsorait. Ez a fajta csere nem kötelező.
A kiszolgálónak meg kell valósítania a témacsere típusát, ebben az esetben a kiszolgálónak először deklarálnia kell legalább egy amq.topic nevű témacserét minden virtuális gazdagépen.
A fejléccsere típusaA fejléccsere típusa így működik:
Az illesztési algoritmust egy speciális kötési argumentum vezérli, amely név-érték párként van átadva az argumentumtáblázatban. Ezt az argumentumot "X-match"-nek nevezik. Két érték közül az egyiket veheti fel, amelyek meghatározzák, hogy a táblázatban lévő többi névérték pár hogyan kerül kezelésre az egyeztetés során:
A kötési argumentumok egyik mezője megegyezik az üzenet mezőjével, ha a következő feltétel igaz: vagy a kötési argumentumokban szereplő mezőnek nincs értéke, és az azonos nevű mező szerepel az üzenet fejlécében, vagy ha a mező az összerendelésben argumentum értéke van, és az azonos nevű mező szerepel a fejlécüzenetekben, és ugyanaz a jelentése.
Az „X-match” kivételével minden „x -” karakterrel kezdődő mező a jövőbeni használatra van fenntartva, és figyelmen kívül lesz hagyva
A kiszolgálónak megvalósítania KELL a fejléccsere-típust, és a kiszolgálónak minden virtuális gazdagépen előre KELL deklarálnia legalább egy amq.match nevű fejléccsere-típust.
A rendszercsere típusaA rendszercsere típusa a következőképpen működik:
Rendszerszolgáltatások az "amq." AMQP számára fenntartva. Minden más név használható. Ez a fajta csere nem kötelező.
Egyéni cseretípusokMinden egyéni cseretípus nevének "x -" karakterrel kell kezdődnie. A nem "x -" karakterrel kezdődő cseretípusok az AMQP szabvány jövőbeni felhasználására vannak fenntartva.
ÜzenetsorokAz üzenetsor egy elnevezett FIFO, amely alkalmazások üzeneteit tartalmazza. Az alkalmazások saját hatáskörükön belül szabadon hozhatnak létre, oszthatnak meg, használhatnak és semmisíthetnek meg üzenetsorokat.
Vegye figyelembe, hogy ha egy sorból vagy ügyféltranzakciókból több olvasó is van, vagy prioritási mezőket használ, vagy üzenetválasztókat vagy megvalósítás-specifikus kézbesítés-optimalizálást használ, előfordulhat, hogy a sor nem rendelkezik valódi FIFO-jellemzőkkel. A FIFO garantálásának egyetlen módja, ha csak egy fogyasztó csatlakozik a sorhoz. Ezekben az esetekben a sor „gyenge FIFO”-ként írható le.
Az üzenetsorok lehetnek állandóak, ideiglenesek vagy automatikusan törölhetők. Állandó üzenetsorok léteznek, amíg el nem távolítják őket. Ideiglenes üzenetsorok léteznek a kiszolgáló leállításáig. Az automatikus törlési sorok addig tartanak, amíg használaton kívül nem lesznek.
Az üzenetsorok a memóriában, a lemezen vagy a kettő kombinációjában tárolják üzeneteiket. Az üzenetsorok elnevezése a virtuális gazdagép alapján történik.
Az üzenetsorok üzeneteket tartalmaznak, és elküldik azokat egy vagy több fogyasztói ügyfélnek. Egy üzenetsorba küldött üzenet soha nem kerül elküldésre egynél több ügyfélnek, hacsak nem utasították el
Egy üzenetsor egyszerre és egymástól függetlenül különböző típusú tartalmat tartalmazhat. Vagyis ha a fő tartalom és a fájltartalom ugyanabba az üzenetsorba kerül, akkor kérésre egymástól függetlenül kézbesítik a fogyasztó alkalmazásokhoz.
KötésekA kötés az üzenetsor és az adatcsere közötti kapcsolat. A kötés határozza meg az útválasztási argumentumokat, amelyek megmondják a központnak, hogy a sornak mely üzeneteket kell kapnia. Az alkalmazások szükség szerint kötéseket hoznak létre és semmisítenek meg, hogy az üzenetek áramlását az üzenetsoraikra irányítsák. Az összerendelés élettartama attól függ, hogy mely üzenetsorokhoz vannak meghatározva – ha egy üzenetsor megsemmisül, a kötése is megsemmisül. A Queue.Bind metódus konkrét szemantikája a cseretípustól függ.
Fogyasztók - fogyasztókA fogyasztó kifejezést az ügyfélalkalmazásra és az entitásra egyaránt használjuk, amely szabályozza, hogy egy adott ügyfélalkalmazás hogyan fogadja az üzeneteket az üzenetsorból. Amikor egy kliens "fogyasztót indít", létrehoz egy fogyasztói entitást a szerveren. Amikor egy kliens "lemond egy fogyasztót", megsemmisíti a fogyasztó entitást a szerveren. A fogyasztók ugyanahhoz az ügyfélcsatornához tartoznak, és arra kényszerítik az üzenetsort, hogy aszinkron módon küldjön üzeneteket az ügyfélnek.
Szolgáltatás minőségeA szolgáltatás minősége határozza meg az üzenetek küldésének sebességét. A szolgáltatás minősége a terjesztett tartalom típusától függ. Általában a QoS az "előzetes letöltés" fogalmát használja annak jelzésére, hogy hány üzenetet vagy hány oktett adatot küldenek el, mielőtt a kliens nyugtázza az üzenetet. A cél az üzenetadatok idő előtti elküldése a késleltetés csökkentése érdekében.
KöszönetnyilvánításA nyugtázás egy formális jelzés az ügyfélalkalmazástól az üzenetsor felé, hogy sikeresen feldolgozta az üzenetet. Két érvényesítési modell lehetséges:
Az ügyfélrétegek maguk is különféle módokon hajthatnak végre kifejezett megerősítéseket, például közvetlenül az üzenet fogadása után, vagy amikor egy alkalmazás jelzi, hogy feldolgozta azt. Ezek a különbségek nem érintik az AMQP-t vagy az interoperabilitást.
áramlásszabályozásAz áramlásvezérlés egy vészhelyzeti eljárás, amelyet a partnertől érkező üzenetek áramlásának leállítására használnak. Ugyanúgy működik a kliens és a szerver között, és a Channel.Flow parancs valósítja meg. A Flow Control az egyetlen mechanizmus, amely megállíthatja a túlproduktív kiadót. A Fogyasztó elegánsabb ablak-előletöltési mechanizmust használhat, ha a Nyugtázást használja (ami általában tranzakciók használatát jelenti).
Elnevezési konvencióEzek a konvenciók szabályozzák az AMQP entitások elnevezését. A kiszolgálónak és a kliensnek tiszteletben kell tartania az alábbi szabályokat:
Az AMQP metódusok minimális értékeket határozhatnak meg (például az üzenetsorban lévő fogyasztók számát) kompatibilitási okokból. Ezeket a minimumokat az egyes osztályok leírása határozza meg.
A megfelelő AMQP implementációknak meglehetősen nagyvonalú értékeket kell megvalósítaniuk az ilyen mezőkben, a minimumok csak a legkevésbé alkalmas platformokon használhatók.
A nyelvtan ezt a jelölést használja:
A módszereket a következőképpen határozzuk meg:
A szabványos AMQP portszámot az IANA 5672 -ként rendelte hozzá mind a TCP, mind az UDP számára. UDP-port a jövőbeni multicast megvalósításokhoz fenntartva
Teljes nyelvtant biztosítunk az AMQP-hez (ez referenciaként szolgál, és érdemes lehet követni azokat a részeket, amelyek részletezik a különböző típusú kereteket és azok formátumait):
amqp = protokoll - fejléc * amqp - egység protokoll - fejléc = literál - AMQP protokoll - azonosító protokoll - verzió literál - AMQP = % d65 .77.81.80 ; "AMQP" protokoll - id = % d0 ; 0 -nak kell lennie protokoll verzió = % d0.9.1 ; _ _ 0-9-1 metódus = módszer - keret [ tartalom ] módszer - keret = % d1 keret - tulajdonságok módszer - hasznos terhelés keret - vége keret - tulajdonságok = csatorna hasznos terhelés - mérete csatorna = short - uint ; nem - nulla hasznos teher - méret = hosszú - uint módszer - hasznos teher = osztály - id metódus - id * amqp - mező osztály - azonosító = % x00 .01 - % xFF . FF metódus - id = % x00 .01 - % xFF . FF amqp - mező = BIT / OCTET / short - uint / long - uint / long - long - uint / short - string / long - string / időbélyeg / mező - táblázat rövid - uint = 2 * OCTET hosszú - uint = 4 * OCTET hosszú - hosszú - uint = 8 * OCTET short - string = OCTET * string - char ; hossza + tartalom string - char = % x01 .. % xFF long - string = long - uint * OCTET ; hossza + tartalom időbélyeg = long - long - uint ; 64 bites POSIX _ mező - táblázat = hosszú - uint * mező - érték - pár mező - érték - pár = mező - név mező - érték mező - név = rövid - karakterlánc mező - érték = 't' logikai érték / 'b' rövid - rövid - int / 'B' rövid - rövid - uint / 'U' rövid - int / 'u' rövid - uint / 'I' long - int / 'i' long - uint / 'L' long - long - int / 'l' long - long - uint / 'f' úszó / 'd' duplájára / 'D' decimális - érték / 's' rövid - string / 'S' hosszú - húr / 'A' mező - tömb / "T" időbélyeg / 'F' mező - táblázat / 'V' ; nincs mező logikai = OCTET ; 0 = HAMIS , különben IGAZ short - short - int = OCTET short - short - uint = OCTET rövid - int = 2 * OCTET hosszú - int = 4 * OCTET long - long - int = 8 * OCTET float = 4 * OCTET ; IEEE -754 dupla = 8 * OCTET ; rfc1832 XDR dupla decimális - érték = skála hosszú - uint skála = OCTET ; decimális számjegyek száma _ mező - tömb = long - int * mező - érték ; értékek tömbje _ keret - vége = % xCE tartalom = % d2 tartalom - fejléc * tartalom - törzs tartalom - fejléc = keret - tulajdonságok fejléc - hasznos teher keret - vége fejléc - hasznos teher = tartalom - osztály tartalom - súlytartalom - test - méret tulajdonság - zászlók tulajdonság - lista tartalom - osztály = oktett tartalom - tömeg = % x00 tartalom - test - méret = hosszú - hosszú - uint tulajdonság - zászlók = 15 * BIT % b0 / 15 * BIT % b1 tulajdonság - jelzők tulajdonság - lista = * amqp - mező tartalom - törzs = % d3 keret - tulajdonságok törzs - hasznos teher keret - vége test - hasznos teher = * OCTET szívverés = % d8 % d0 % d0 keret - vége
Az IETF RFC 2234-ben meghatározott kiterjesztett BNF szintaxist használjuk. Összefoglalva:
A kliensnek új kapcsolatot kell indítania a protokoll fejlécének elküldésével. Ez egy 8 oktettből álló sorozat:
+---+---+---+---+---+---+---+---+ | 'A' | "M" | 'Q' | "P" | 0 | 0 | 9 | 1 | +---+---+---+---+---+---+---+---+ 8 oktettA protokoll fejléce az "AMQP" nagybetűkből áll, amelyeket a %d0 konstans követ, majd ezt követi:
A protokollegyeztetési modell kompatibilis a meglévő protokollokkal, például a HTTP-vel, amelyek állandó szöveges karakterlánccal kezdeményeznek kapcsolatot, valamint a tűzfalakkal, amelyek figyelik a protokoll elejét, hogy eldöntsék, milyen szabályokat alkalmazzanak rá.
A kliens és a szerver a következőképpen egyeztet a protokollról és a verzióról:
Példa:
A kliens elküldi : A szerver válaszol : AMQP % d0 .0.9.1 Csatlakozás . indítási módszer AMQP % d0 .1.0.0 AMQP % d0 .0.9.1 < Kapcsolat bezárása > HTTP AMQP % d0.0.9.1 < Kapcsolat bezárása > _A protokoll végrehajtásának elvei:
Minden keret egy 7 oktettből álló fejléccel kezdődik, amely egy típusmezőből (oktett), egy csatornamezőből (rövid egész szám) és egy hosszmezőből (hosszú egész szám) áll:
0 1 3 7 méret + 7 méret + 8 +------+----------+---------+ +--------------+ +------- -----+ | típus | csatorna | méret | | hasznos teher | | keret - vége | +------+----------+---------+ +--------------+ +------- -----+ oktett rövid hosszú ' méret ' oktett oktettAz AMQP a következő kerettípusokat határozza meg:
A csatornaszám 0 minden olyan keret esetében, amely globális a kapcsolathoz, és 1-65535 a meghatározott csatornákra hivatkozó keretekhez.
A méretmező a hasznos teher mérete, a keretvégi oktett nélkül. Míg az AMQP megbízható csatlakoztatott protokollt feltételez, a keret végét használjuk a nem megfelelő kliens- vagy szervermegvalósítások által okozott keretezési hibák észlelésére.
A protokoll végrehajtásának elvei:
A metódus kerettestek adatmezők invariáns listájából, úgynevezett „argumentumokból” állnak. Minden metódustörzs osztály- és metódusazonosítókkal kezdődik:
0 2 4 +----------+----------------------------- - - | osztály - azonosító | módszer - id | érvek ... +----------+----------------------------- - - rövid rövid ...A protokoll végrehajtásának elvei:
Az AMQP két szintű adatmező-specifikációval rendelkezik: a metódus argumentumokhoz használt natív adatmezők és a mezőtáblákban lévő alkalmazások között átadott adatmezők. A mezőtáblák natív adatmezők felső indexét tartalmazzák.
Az AMQP a következő natív egész típusokat határozza meg:
Az egész számok és a karakterláncok hossza mindig előjel nélküli, és hálózati bájt sorrendben tárolódik. Nem azt az esetet próbáljuk optimalizálni, amikor két alacsony-magas rendszer (pl. két Intel processzor) beszél egymással.
A protokoll végrehajtásának elvei:
Az AMQP meghatározza a saját bitmező típusát. A bitek egész oktettekre halmozódnak fel. Ha egy keretben két vagy több bit érintkezik, egy vagy több oktettbe csomagolódnak, minden oktett legalacsonyabb bitjével kezdve. Nincs követelmény, hogy egy keretben az összes bitérték egybefüggő legyen, de ez általában a keretméretek minimalizálása érdekében történik.
StringsAz AMQP karakterláncok változó hosszúságúak, és egy egész szám, amelyet nulla vagy több adatoktett követ. Az AMQP két natív sortípust határoz meg:
Az időbélyegek tárolása 64 bites POSIX time_t formátumban történik, egy másodperces pontossággal. A 64 bites használatával elkerüljük a 31 bites és 32 bites time_t értékekhez kapcsolódó jövőbeni tördelési problémákat.
Táblázat margóiA táblázat mezői hosszú karakterláncok, amelyek csomagolt név-érték párokat tartalmaznak. A névérték párok egy rövid karakterláncként vannak kódolva, amely megadja a nevet, és egy oktettként, amely az érték típusát adja meg, majd ezt követi maga az érték. A táblázatok érvényes mezőtípusai az integer, bit, string és timestamp natív típusok kiterjesztései, és a nyelvtanban láthatók. A több oktettet tartalmazó egész mezők mindig hálózati bájt sorrendben kerülnek tárolásra.
A protokoll végrehajtásának elvei:
Bizonyos meghatározott módszerek (közzététel, kézbesítés stb.) feldolgozzák a tartalmat. Az egyes módszerek specifikációit a "Funkcionális specifikációk" fejezetben találja. A tartalmat feldolgozó módszerek feltétel nélkül ezt teszik.
A tartalom egy vagy több képkockát tartalmazó listából áll, az alábbiak szerint:
A tartalom képkockái egy adott csatornán szigorúan egymás után következnek. Vagyis keverhetők más csatornák képkockáival, de nem keverhető két tartalomkeret ugyanarról a csatornáról, és nem „fedhetik át” egymást, valamint az azonos tartalomhoz tartozó tartalomkeretek nem keverhetők össze ugyanazon a csatornán lévő metóduskockákkal. . (eredeti. Egy adott csatornán lévő tartalomkockák szigorúan egymás után következnek. Vagyis keverhetők más csatornák képkockáival, de nem keverhetők vagy fedhetők át két tartalomkeret ugyanabból a csatornából, és egyetlen tartalom tartalomkockái sem keverhetők össze. keverve metódus keretekkel ugyanazon a csatornán.)
Vegye figyelembe, hogy minden nem tartalmi keret kifejezetten a tartalom végét jelzi. Míg a tartalom mérete jól ismert a tartalom fejlécéből (és így a tartalomkockák száma), ez lehetővé teszi a feladó számára, hogy megszakítsa a tartalmat anélkül, hogy be kellene zárnia a csatornát.
A protokoll végrehajtásának elvei:
A tartalom hasznos fejlécének formátuma a következő:
0 2 4 12 14 +----------+--------+-----------+----------------+ ------------- --- _ | osztály - azonosító | súly | testméret | _ ingatlan zászlók | ingatlan lista ... +----------+--------+-----------+----------------+ ------------- --- _ rövid rövid hosszú hosszú rövid maradék ...A protokoll végrehajtásának elvei:
A tartalomtörzs hasznos terhelése egy "átlátszatlan" bináris blokk, amely egy keretvégi oktettre végződik:
+----------------------+ +------------+ | Átlátszatlan bináris hasznos teher | | keret - vége | +----------------------+ +------------+A tartalomtörzs tetszőleges számú keretre osztható. A maximális hasznos adattartalom méretét mindkét partner egyezteti a kapcsolat egyeztetése során.
A protokoll végrehajtásának elvei:
A szívverés keretei jelzik a címzettnek, hogy a küldő még életben van. A Heartbeat keretek gyakorisága és időzítése a kapcsolat beállítása során egyeztetésre kerül.
A protokoll végrehajtásának elvei:
Az AMQP lehetővé teszi a társaknak, hogy több független vezérlési folyamatot hozzanak létre. Minden csatorna virtuális kapcsolatként működik, amely egy aljzaton osztozik:
keretek keretek keretek keretek +-----------+-----------+------------+------------+ | csatorna | csatorna | csatorna | csatorna | +-----------+-----------+------------+------------+ | aljzat | +-------------------------------------------------- ----+A protokoll végrehajtásának elvei:
A szervernek biztosítania kell, hogy a kliens megfigyelései a szerver állapotáról konzisztensek legyenek.
A következő példa bemutatja, mit jelent ebben az összefüggésben az ügyfél megfigyelése:
A láthatósági garancia biztosítja, hogy a 2. ügyfél látja a sort
A szerver lezártnak tekinti a csatornát, ha a következők bármelyike megtörténik:
Amikor a szerver bezár egy csatornát, a csatornán lévő összes nyugtázatlan üzenet megjelölésre kerül újrakézbesítésre. Amikor a szerver bezár egy kapcsolatot, eltávolítja a kapcsolathoz tartozó összes automatikusan törölt entitást.
Egyes esetekben a szinkron kérés-válasz módszerek befolyásolják a tartalom aszinkron kézbesítését ugyanazon a csatornán, beleértve:
A protokoll végrehajtásának elvei:
A metódusok csatornán való áthaladásának sorrendje stabil: a metódusok vétele ugyanabban a sorrendben történik, amelyben elküldik őket. A szállítási rétegben ezt a TCP/IP protokoll biztosítja. Ráadásul a tartalmat stabilan dolgozza fel a szerver. Különösen azok a tartalmak maradnak rendezve, amelyek a szerveren belül ugyanazt az utat követik. Egy adott prioritású, egyetlen útvonalon áthaladó tartalom esetén a tartalomfeldolgozási útvonalat úgy határozzuk meg, hogy egy bejövő csatornából, egy központból, egy sorból és egy kimenő csatornából áll.
A protokoll végrehajtásának elvei:
A szabványos "kivételek" programozási modellt használva az AMQP nem jelzi a sikert, csak a kudarcot. Az AMQP a kizárások két szintjét határozza meg:
Formálisan dokumentáljuk az állításokat az egyes osztályok és metódusok definíciójában.
Válaszkód formátumaAz AMQP válaszkódok követik az IETF RFC 2821 „Válaszkód súlyossága és elmélete” definícióját.