Introduktion till AMQP-protokollet
AMQP (Advanced Message Queuing Protocol) är ett standardprotokoll på applikationslagret som tillhandahåller enhetliga meddelandetjänster och är en öppen standard för applikationslagersprotokoll designade för meddelandeorienterad middleware. AMQP är ett nätverksprotokoll för att skicka asynkrona meddelanden mellan processer.
Klienter och meddelandemellanvara baserade på detta protokoll kan leverera meddelanden utan att vara begränsade av olika klient-/mellanvaruprodukter, olika utvecklingsspråk osv.
De viktigaste egenskaperna hos AMQP är meddelandeorienterad, köplacerad, routing (inklusive peer-to-peer och publicish/subscribe), tillförlitlighet och säkerhet. AMQP upprätthåller beteendet hos meddelandeleverantörer och klienter, vilket möjliggör verklig interoperabilitet mellan olika leverantörer.
AMQP och JMS
JMS var ett försök att standardisera tidig meddelande-middleware, det standardiserades endast på API-nivå och var långt ifrån att skapa interoperabilitet.
Till skillnad från JMS är AMQP ett trådnivåprotokoll som beskriver formatet för data som överförs över ett nätverk, flytande i bytes. Som ett resultat är alla verktyg som följer detta dataformat, vilka skapar och tolkar meddelanden, interoperabla med andra kompatibla verktyg.
AMQP:s kärnsammansättning
Producent
Produktionsnyheter.
ConnectionFactory
Fabriken som tillverkar Connection.
Samband
Anslutning, applikationsnätverksanslutning med Broker TCP/IP/Triple Handshake och Quad Wave.
AMQP-anslutningar är vanligtvis långa förbindelser. AMQP är ett applikationslagsprotokoll som använder TCP för att tillhandahålla tillförlitlig leverans. AMQP använder autentiseringsmekanismer och tillhandahåller TLS (SSL)-skydd. När en applikation inte längre behöver ansluta till AMQP-proxyn behöver den smidigt släppa AMQP-anslutningen istället för att helt enkelt stänga ner TCP-anslutningen.
Kanal
Nätverkskanalen är en lättviktig anslutning byggd ovanpå anslutningen. Nästan alla operationer utförs i kanaler, som är kanaler för att läsa och skriva meddelanden, och klienter kan etablera par för varje kanal, där varje kanal representerar en sessionsuppgift.
Om anslutningen jämförs med en fiberoptisk kabel, jämförs kanalkanalen med en av fibrerna i en fiberoptisk kabel. Valfritt antal kanaler kan skapas på en anslutning.
De flesta av våra affärsoperationer sker i kanalgränssnittet, inklusive:
- queueDeklarationT
- ExchangeDeclar för switchen
- queueBind queueBind
- Publicera meddelandet basicPublish
- Konsumentnyheter, basicConsume, etc.
Mäklare
Acceptera klientens anslutning för att implementera AMQP-entitetstjänster, såsom rabbitmq.
VirtualHost (webbhotell)
Virtuell hosting, som används för logisk isolering, en virtuell värd kan ha flera utbyten och köer, och samma virtuella värd kan inte ha utbyten med samma namn.
För att implementera flera isolerade miljöer (användare, användargrupper, switchar, köer, etc.) på en enda proxy, tillhandahåller AMQP konceptet virtuella värdar (virtuella värdar – vhosts). Detta liknar mycket webbserverkonceptet, som erbjuder en helt isolerad miljö för AMQP-enheter. När anslutningen är etablerad specificerar AMQP-klienten vilken virtuell värd som ska användas.
Utbyte
Switchen tar emot meddelanden och skickar meddelanden till den bundna kön baserat på routningsnyckeln (utan möjlighet till meddelandelagring).
En switch är en AMQP-enhet som används för att skicka meddelanden. Efter att switchen fått ett meddelande dirigerar den det till en eller noll köer. Den routningsalgoritm den använder bestäms av switchtypen och bindningsreglerna.
Brytartyp:
- Direkt utbyte
- Utflyktsutbyte
- Ämnesutbyte
- Headersutbyte
Switchens egenskaper:
- Namn: Namnet på växeln
- Hållbarhet: En persistensflagga som visar om denna switch är kvar eller inte
- Auto-delete: Delete-flaggan, som indikerarNär alla köer är klara via denna utväxling, oavsett om de raderas
- Argument: Beroende av själva agenten
Switchstatus:
Persistenta switchar kommer att finnas kvar efter att mäklaren startats om, medan staging-switchar inte gör det (de måste deklareras om efter att mäklaren är online igen).
Standardbrytare
Standardutbytet är faktiskt en direkt utbyte som är fördeklarat av meddelandemäklaren och har inget namn (namnet är en tom sträng).
Du kan tänka på standardbrytaren som en speciell direktansluten switch.
Standardomkopplingsnamn: Nullsträng (AMQP standard)
Standardtyp av switch: Direktansluten switch
När man skapar en kö, så länge switchen som ska bindas inte specificeras, kommer den automatiskt att bindas till standardswitchen, och routningsnyckelns namn för bindningen kommer att vara detsamma som köns namn.
Direkt anslutning till växeln
En direktansluten switch levererar meddelanden till en kö av motsvarande bindningstangenter baserat på den routningsnyckel som meddelandet bär. Unicast-routningen används av direktswitchen för att hantera meddelandet.
När man skapar en kö, om den är bunden till en direktväxel, behöver den inte ange namnet på routningsnyckeln, eftersom den då har ett standardnamn på routningsnyckeln, vilket är samma som köens namn.
En kö av direktanslutna switchar distribuerar vanligtvis uppgifter till flera konsumenter i en loop (vi kallar detta polling).
Arbetsflöde:
- När du binder en kö till en switch, ge den en bindningsnyckel, med antagandet R;
- När ett meddelande med en routingnyckel skickas till en direktansluten switch, leder switchen det till en kö med en routingnyckel.
Fläktbrytare
Fläktbrytaren leder meddelanden till alla köer som är bundna till den, oavsett den bundna routingnyckeln.
Om N köer är bundna till en sektorväxel, skickar växeln en kopia av meddelandet till alla N köer separat när ett meddelande skickas till denna sektorswitch. Fläktbrytare används vanligtvis för att hantera sändningsroutning av meddelanden.
Tillämpningsscenarier:
sända meddelanden;
Gruppchattsfunktion.
Temabyte
Ämnesbytet skickar meddelanden till en eller flera köer enligt routningsnyckeln och typen av Exchange, och vi använder det ofta för att implementera olika publicera/prenumerera, det vill säga publicera prenumerationer.
Ruttningsreglerna för direktanslutna switchar är strikt matchade, vilket innebär att routningsnyckeln måste matcha bindningsnyckeln innan ett meddelande skickas till kön.
Routingreglerna för ämnesbytet är fuzzy-matcher som kan levereras genom att uppfylla vissa regler via jokrar.
Den föreskriver:
- Det kan finnas två specialtecken * och # i bindningsknappen för fuzzy matchning. där * används för att matcha ett ord, #用于匹配多个单词 (kan vara noll)
- En routnyckel är en punktseparerad sträng (vi kallar varje enskild sträng separerad av en prick för ett ord)
- När producenten skickar meddelandet Routing Key=A.A.A, är endast A.*.* tillfredsställd, och det kommer endast att routas till kö1.
- När producenten skickar meddelandet Routing Key=A.B.A, kommer de som uppfyller A.*.* och *.B.* att routas till kö1 och kö2.
- När producenten skickar meddelandet Routing Key=A.B.C, är A.*..* och *.B.* och *.* tillfredsställda. C dirigeras till kö1, kö2, kö3.
Tillämpningsscenarier:
- nyhetsuppdateringar med kategorier eller taggar;
- Bakgrundsuppgifter utförda av flera arbetare, var och en ansvarig för att hantera vissa specifika uppgifter.
Huvudbrytare
Headers-switchar förlitar sig inte på matchningsreglerna för routningsnyckeln för att binda nycklar till att routa meddelanden, utan matchas istället baserat på headers-attributet i innehållet i det skickade meddelandet.
Huvudbrytare kan betraktas som en annan manifestation av en direktansluten strömbrytare. Dock måste routningsnyckeln för en direktväxel vara en sträng, och headerattributvärdena begränsas inte av detta, de kan till och med vara heltal eller hashvärden (ordböcker), etc. Mer flexibilitet (men i praktiken använder vi sällan huvudbrytare).
Arbetsflöde:
- När en kö är bunden till en headerswitch binds flera headers samtidigt för matchning.
- Inkommande meddelanden bär på en header och en "x-match"-parameter. När "x-match" är satt till "vilken som helst" kan vilket värde som helst i headern matchas, och när "x-match" sätts till "alla" måste alla värden i headern matchas.
Bytessammanfattning
Bindande
Virtuell anslutning mellan Exchange och Queue.
BindingKey är en regelbeskrivning för Exchange- och Queue-bindningar. Bindningsnyckeln specificerar vilken typ av Routingnyckel som ska tilldelas den för närvarande bundna kön under den aktuella utbytet.
Routingnyckel
Ruttningsregler, som den virtuella maskinen kan använda för att avgöra hur ett visst meddelande ska dirigeras.
Bindningsnyckel vs. routingnyckel
- Bindningsnyckeln är bindningsknappen mellan kön och switchen;
- Routingnyckeln är en informationsbit som tillverkaren skickar till switchen;
- När bindningsnyckeln och routningsnyckeln stämmer överens, lägg meddelandet i motsvarande kö.
Bindningsnyckel är regelbeskrivningen för Exchange och köbindning, som används för att tolka när Exchange tar emot ett meddelande, meddelandet som tas emot av Exchange har ett routningsnyckelfält, och Exchange matchar denna routningsnyckel med alla bindande nycklar i den aktuella Exchange, och om kraven uppfylls skickas den till Bindning Nyckeln är bunden till kön för att skicka meddelandet.
Bindningsnyckel vs. routningsnyckel i olika switchar
Standardswitch: Bindningsnyckeln är köns namn, som inte kan anpassas. Routingnyckeln är också könamnet innan den kan routas framgångsrikt till kön
Direktanslutningsswitch: Bindningsnyckeln är köns namn, som kan anpassas. Routingnycklar kan endast framgångsrikt routas till kön när bindningsnyckeln är densamma
Fläktbrytare: Ingen bindningsknapp; Självklart finns det ingen routing key. Automatiskt routad till alla köer som är bundna till switchen
Temabyte: anpassad bindningsnyckel; Anpassa routingnyckeln. Routing Key==Bindningsnyckel, och fuzzy-matchningen måste framgångsrikt routas till kön
Huvudbrytare: ingen bindningsknapp; Självklart finns det ingen routing key. Matchningar baserade på headers-attributet i innehållet i det skickade meddelandet
Kö
Lagrar meddelanden som är på väg att konsumeras av appen.
Köegenskaper:
- Namn: Köns namn
- Beständig: Kön finns fortfarande kvar efter att meddelandemäklaren startats om
- Exklusiv: Används endast av en anslutning, och kön tas bort när anslutningen stängs
- Auto-radering: Raderad när den senaste konsumenten avprenumererar
- Argument: Vissa meddelandemäklare använder det för att utföra extra funktioner liknande TTL
Köskapande:
Köer kan bara användas efter att de har deklarerats. Om en kö inte redan finns, skapar deklaration av en kö den. Om den deklarerade kön redan existerar och attributen är identiska, har deklarationen ingen effekt på den ursprungliga kön. Om attributen i deklarationen skiljer sig från de i den befintliga kön, kastas ett kanalnivåundantag med felkoden 406.
Köbeständighet:
Persistenskön lagras på disken och förblir där när mäklaren startas om. Köer som inte är kvarvarande kallas transienta köer. Inte alla scenarier och fall kräver köbeständighet.
En bestående kö gör inte meddelanden som routas till den beständiga. Om meddelandeagenten lägger på och startas om, kommer persistenskön att deklareras på nytt under omstarten, och i vilket fall som helst kan endast kvarstående meddelanden återställas.
Konsument
Konsumentkonsumtionsnyheter. I AMQP finns det två sätt för konsumenter att få väntande meddelanden:
Meddelande-middleware levererar meddelanden till konsumenter (push-API)
Konsumenter får aktivt meddelanden (pull API)
Observera: När flera konsumenter lyssnar på samma kö kommer meddelandena i kön endast att konsumeras av en av konsumenterna (inte en gång per konsument)
Meddelande
Data som överförs mellan meddelanden, tjänster och applikationer består av egenskaper och kroppar.
Attribut ändrar meddelanden, såsom meddelandets prioritet, fördröjning och andra avancerade funktioner, och huvuddelen är innehållet i meddelandets kropp.
Meddelandeegenskaper:
- Innehållstyp
- Innehållskodning
- Routingnyckel
- Leveransmetod (persistent eller inte)
- Leveransmetod (persistent eller icke-persistent)
- Meddelandets prioritet
- Tidsstämpel för meddelandepublicering
- Utgångstid
- Publicistapplikations-id
Meddelandets brödtext:
Utöver attributen innehåller AMQP-meddelanden även en nyttolast (den data som meddelandet faktiskt bär), som behandlas av AMQP-proxyn som en ogenomskinlig bytematris.
Meddelandemäklaren inspekterar eller ändrar inte nyttolasten. Meddelanden kan endast innehålla attribut utan att bära en nyttolaste. Den använder vanligtvis data i ett serialiserat format som JSON, och för att spara pengar serialiserar protokollbuffertar och MessagePacks den strukturerade datan för publicering som en nyttolast av meddelanden. AMQP och dess motsvarigheter använder vanligtvis fälten "innehållstyp" och "innehållskodning" för att kommunicera med meddelanden och identifiera nyttolaster, men detta baseras endast på konventioner.
Meddelandets beständighet:
Meddelanden publiceras på ett beständigt sätt, och AMQP-agenten lagrar detta meddelande på disken. Om servern startas om bekräftar systemet att det mottagna persistensmeddelandet inte är förlorat.
Att bara skicka ett meddelande till en persistent switch eller routa det till en persistent kö gör inte meddelandet persistent: meddelandets persistens beror helt på meddelandets persistensläge.
Att publicera meddelanden på ett beständigt sätt kan ha en prestandapåverkan.
AMQP:s arbetsprocess
Förlaget publicerar ett meddelande via Exchange.
Switchen distribuerar de inkommande meddelandena till kön som är bunden till switchen enligt routningsreglerna.
Slutligen levererar AMQP-agenten meddelandet till konsumenten som prenumererat på denna kö, eller så hämtar konsumenten det själv vid behov.
AMQP-meddelandemekanism
Meddelandebekräftelse
Konsumenter misslyckas ibland med att bearbeta meddelanden eller kraschar direkt. Och nätverksorsaker kan också orsaka olika problem.
Detta ställer oss inför frågan om när det är rätt tid för AMQP-agenter att radera meddelanden.
AMQP:s två meddelandebekräftelselägen:
Auto-Confirm-läge: Ta bort meddelandet så snart det skickas till konsumenten av meddelande-middleware. (Med AMQP-metoden: basic.deliver eller basic.get-ok)
Explicit bekräftelseläge: Vänta på att konsumenten skickar en bekräftelse innan meddelandet raderas. (Med AMQP-metoden: basic.ack)
Om en konsument lägger på utan att skicka ett kvitto för bekräftelse, levererar AMQP-agenten meddelandet till en annan konsument. Om det inte finns några tillgängliga konsumenter vid den tidpunkten väntar meddelandemäklaren på att nästa konsument ska registrera sig i denna kö och försöker sedan leverera igen.
Avvisa meddelanden
När en konsument tar emot ett meddelande kan bearbetningsprocessen lyckas eller misslyckas. Konsumenten kan indikera för meddelandemäklaren (meddelandemellanvaran) att meddelandet inte behandlades (eller inte slutfördes vid denna tidpunkt) på grund av ett "avvisat meddelande".
När ett meddelande avvisas kan konsumenten tala om för meddelandemäklaren vad meddelandet ska göras med – förstöra det eller lägga tillbaka det i kön.
När det bara finns en konsument i denna kön, se till att du inte avvisar meddelandet och väljer att lägga tillbaka det i kön, vilket gör att meddelandet loopar obegränsat på samma konsument.
I AMQP används metoden basic.reject för att utföra operationen att avvisa meddelanden. Dock har basic.reject en begränsning: du kan inte använda det för att avvisa flera meddelanden med bekräftelser. Men om du använder RabbitMQ kan du använda AMQP 0-9-1-tillägget som kallas negativa bekräftelser (även kallat nacks) för att lösa detta problem.
Original:Inloggningen med hyperlänken är synlig.
|
Publicerad på 2022-08-14 23:22:55
|
|
|
|
