Introduktion til AMQP-protokollen
AMQP (Advanced Message Queuing Protocol) er en applikationslagsstandardprotokol, der tilbyder ensartede beskedtjenester, og er en åben standard for applikationslagsprotokoller designet til meddelelsesorienteret middleware. AMQP er en netværksprotokol til udveksling af asynkrone beskeder mellem processer.
Klienter og beskedmiddleware baseret på denne protokol kan levere beskeder uden at være begrænset af forskellige klient-/middlewareprodukter, forskellige udviklingssprog osv.
De vigtigste karakteristika ved AMQP er meddelelsesorienteret, købaseret, routing (inklusive peer-to-peer og publicish/subscribe), pålidelighed og sikkerhed. AMQP håndhæver adfærden hos beskedudbydere og klienter, hvilket muliggør ægte interoperabilitet mellem forskellige leverandører.
AMQP og JMS
JMS var et forsøg på at standardisere tidlig beskedmiddleware, det var kun standardiseret på API-niveau, og det var langt fra at skabe interoperabilitet.
I modsætning til JMS er AMQP en wire-level protokol, der beskriver formatet for data, der transmitteres over et netværk og flyder i bytes. Som følge heraf er ethvert værktøj, der følger dette dataformat, som opretter og fortolker beskeder, interoperabelt med andre kompatible værktøjer.
AMQP-kernesammensætning
Producer
Produktionsnyheder.
ConnectionFactory
Fabrikken, der producerer Connection.
Forbindelse
Forbindelse, applikationsnetværksforbindelse med Broker TCP/IP/Triple Handshake og Quad Wave.
AMQP-forbindelser er som regel lange forbindelser. AMQP er en applikationslagsprotokol, der bruger TCP til at levere pålidelig levering. AMQP bruger autentificeringsmekanismer og leverer TLS (SSL) beskyttelse. Når en applikation ikke længere behøver at forbinde til AMQP-proxyen, skal den elegant frigive AMQP-forbindelsen i stedet for blot at lukke TCP-forbindelsen ned.
Kanal
Netværkskanalen er en letvægtsforbindelse, der er bygget oven på forbindelsen. Næsten alle operationer udføres i kanaler, som er kanaler til læsning og skrivning af beskeder, og klienter kan etablere par for hver kanal, hvor hver repræsenterer en sessionsopgave.
Hvis forbindelsen sammenlignes med et fiberoptisk kabel, så sammenlignes kanalkanalen med en af fibrene i et fiberoptisk kabel. Et vilkårligt antal kanaler kan oprettes på en forbindelse.
De fleste af vores forretningsoperationer foregår i kanalgrænsefladen, herunder:
- queueDeclarér
- ExchangeDeclar for switchen
- queueBind queueBind
- Udsend beskeden basicPublish
- ForbrugernyhederbasicConsume osv.
Mægler
Accepter klientens forbindelse for at implementere AMQP-enhedstjenester, såsom rabbitmq.
VirtualHost (webhosting)
Virtuel hosting, der bruges til logisk isolation, en virtuel vært kan have flere udvekslinger og køer, og den samme virtuelle vært kan ikke have udvekslinger med samme navn.
For at implementere flere isolerede miljøer (brugere, brugergrupper, switches, køer osv.) på en enkelt proxy, tilbyder AMQP konceptet virtuelle værter (virtuelle værter - vhosts). Dette minder meget om webserverens webhostingkoncept, som giver et fuldstændigt isoleret miljø for AMQP-enheder. Når forbindelsen etableres, specificerer AMQP-klienten, hvilken virtuel vært der skal bruges.
Udveksling
Switchen accepterer beskeder og sender beskeder til den bundne kø baseret på routingnøglen (uden mulighed for meddelelseslagring).
En switch er en AMQP-enhed, der bruges til at sende beskeder. Efter at switchen modtager en besked, dirigerer den den til én eller nul køer. Den routingalgoritme, den bruger, bestemmes af switchtypen og bindingsreglerne.
Kontakttype:
- Direkte udveksling
- Udveksling af fanout
- Emneudveksling
- Udveksling af overskrifter
Switch-egenskaber:
- Navn: Navnet på kontakten
- Holdbarhed: Et persistensflag, der angiver, om denne kontakt er bevaret eller ej
- Auto-slet: Slet-flaget, der indikererNår alle køer er færdige via denne udveksling, uanset om de slettes
- Argumenter: Afhænger af agenten selv
Switch-status:
Vedvarende switches vil eksistere efter mægleren er genstartet, mens staging-switches ikke vil (de skal generklæres, når mægleren er online igen).
Standardkontakt
Standardudvekslingen er faktisk en direkte udveksling, der er foruddeklareret af beskedmægleren og ikke har noget navn (navnet er en tom streng).
Du kan tænke på standardkontakten som en speciel direkte tilsluttet kontakt.
Standard-switchnavn: Null-streng (AMQP standard)
Standard kontakttype: Direkte tilsluttet switch
Når man opretter en kø, så længe switchen, der skal bindes til at være bundet, ikke er specificeret, vil den automatisk være bundet til standardswitchen, og navnet på routingnøglen for bindingen vil være det samme som køens navn.
Direkte forbindelse til kontakten
En direkte tilknyttet switch leverer beskeder til en kø af tilsvarende bindingsnøgler baseret på den routingnøgle, som beskeden bærer. Unicast-routingen, som den direkte switch bruger til at håndtere beskeden.
Når man opretter en kø, hvis den er bundet til en direkte switch, behøver den ikke specificere navnet på routingnøglen, fordi den vil have et standard routingnøglenavn, som er det samme som køens navn.
En kø af direkte tilsluttede switches distribuerer typisk opgaver til flere forbrugere i en løkke (vi kalder dette polling).
Arbejdsgang:
- Når en kø bindes til en switch, giv den en bindingsnøgle, forudsat at R;
- Når en besked med en Routing Key sendes til en direkte tilknyttet switch, dirigerer switchen den til en kø med en Routing Key.
Ventilatorkontakter
Ventilatorkontakten sender beskeder til alle køer, der er bundet til den, uanset den bundne routingnøgle.
Hvis N køer er bundet til en sektorswitch, sender switchen en kopi af beskeden til alle N køer separat, når en besked sendes til denne sektorswitch. Ventilatorkontakter bruges generelt til at håndtere broadcast-routing af beskeder.
Anvendelsesscenarier:
udsendelsesbeskeder;
Gruppechatfunktion.
Temaskift
Emneskiftet sender beskeder til en eller flere køer i henhold til routingnøglen og typen af Exchange, og vi bruger det ofte til at implementere forskellige publicer/abonner, altså publicer-abonnementer.
Routingreglerne for direkte tilsluttede switches er strengt matchede, hvilket betyder, at Routingnøglen skal matche bindingsnøglen, før en besked sendes til køen.
Routingreglerne for emneskiftet er fuzzy-matches, der kan leveres ved at opfylde nogle af reglerne via wildcards.
Den fastslår:
- Der kan være to specialtegn * og # i bindingstasten for fuzzy matching. hvor * bruges til at matche et ord, #用于匹配多个单词 (kan være nul)
- En routingnøgle er en punktus-separeret streng (vi kalder hver enkelt streng adskilt af et punktumstegn for et ord)
- Når producenten sender beskeden Routing Key=A.A.A, er kun A.*.* tilfredsstillet, og den vil kun blive rutet til kø1.
- Når producenten sender beskeden Routing Key=A.B.A, vil opfyldelsen af A.*.* og *.B.* blive rutet til kø1 og kø2.
- Når producenten sender beskeden Routing Key=A.B.C, er A.*.* og *.B.* og *.* tilfredsstillet. C bliver rutet til kø1, kø2, kø3.
Anvendelsesscenarier:
- nyhedsopdateringer med kategorier eller tags;
- Baggrundsopgaver udført af flere medarbejdere, som hver især er ansvarlig for at håndtere bestemte specifikke opgaver.
Hovedkontakt
Header-switches er ikke afhængige af routing-nøglens matchningsregler for at binde nøgler til rute beskeder, men matcher baseret på headers-attributtet i indholdet af den sendte besked.
Hovedkontakter kan betragtes som en anden manifestation af en direkte tilsluttet kontakt. Dog skal routingnøglen for en direkte switch være en streng, og headerattributværdierne er ikke begrænset af dette; de kan endda være heltal eller hashværdier (ordbøger) osv. Mere fleksibilitet (men i praksis bruger vi sjældent hovedkontakter).
Arbejdsgang:
- Når en kø er bundet til en header-switch, bindes flere headere samtidig for at matche.
- Indkommende beskeder bærer en header og en "x-match" parameter. Når "x-match" sættes til "any", kan enhver værdi af headeren matches, og når "x-match" sættes til "alle", skal alle værdier i headeren matches.
Switch-oversigt
Bindende
Virtuel forbindelse mellem Exchange og Kø.
BindingKey er en regelbeskrivelse for Exchange og Queue-bindings. Bindingsnøglen angiver, hvilken type Routing-nøgle der skal tildeles den aktuelt bundne kø under den aktuelle udveksling.
Routingnøgle
Routingregler, som den virtuelle maskine kan bruge til at bestemme, hvordan en bestemt besked skal rutes.
Bindingsnøgle vs. routingnøgle
- Binding-nøglen er bindingsnøglen mellem køen og kontakten;
- Routing Key er en oplysning, som producenten sender til switchen;
- Når bindingsnøglen og routingnøglen svarer sammen, læg beskeden i den tilsvarende kø.
Binding Key er regelbeskrivelsen af Exchange og Queue binding, som bruges til at parse, når Exchange modtager en besked; beskeden modtaget af Exchange vil have et rutenøglefelt, og Exchange matcher denne Routing Key med alle bindingsnøgler i den nuværende Exchange, og hvis kravene er opfyldt, sendes den til Binding Nøglen er bundet til køen for at sende beskeden.
Binding af nøgle vs. routing-nøgle i forskellige switches
Standardkontakt: Binding Key er køens navn, som ikke kan tilpasses. Routingnøglen er også køens navn, før den kan videreføres til køen
Direkte forbindelsesswitch: Binding Key er køens navn, som kan tilpasses. Routingnøgler kan kun route succesfuldt til køen, når bindingsnøglen er den samme
Ventilatorkontakt: Ingen bindingsnøgle; Selvfølgelig er der ingen Routing Key. Automatisk rutet til alle køer bundet til switchen
Tema-skift: brugerdefineret bindingsnøgle; Tilpas routing-nøglen. Routing Key==Bindingsnøgle, og fuzzy-matchet skal med succes rutes til køen
Hovedkontakt: ingen fastgørelsestast; Selvfølgelig er der ingen Routing Key. Matches baseret på headers-attributten i indholdet af den sendte besked
Kø
Gemmer beskeder, der er ved at blive forbrugt af appen.
Køegenskaber:
- Navn: Navnet på køen
- Holdbar: Køen eksisterer stadig, efter at beskedmægleren er genstartet
- Eksklusiv: Bruges kun af én forbindelse, og køen slettes, når forbindelsen lukkes.
- Auto-sletning: Slettet når den sidste forbruger afmelder abonnementet
- Argumenter: Nogle beskedmæglere bruger det til at udføre nogle ekstra funktioner, der ligner TTL
Oprettelse af kø:
Køer kan kun bruges, efter de er erklæret. Hvis en kø ikke allerede eksisterer, opretter deklarationen af en kø den. Hvis den erklærede kø allerede eksisterer, og attributterne er identiske, har erklæringen ingen effekt på den oprindelige kø. Hvis attributterne i deklarationen adskiller sig fra dem i den eksisterende kø, kastes en kanalniveau-undtagelse med fejlkoden 406.
Køpersistens:
Persistenskøen gemmes på disk og forbliver der, når brokeren genstartes. Køer, der ikke er bevaret, kaldes transiente køer. Ikke alle scenarier og sager kræver kø-persistence.
En vedvarende kø gør ikke beskeder, der sendes til den, vedvarende. Hvis meddelelsesagenten lægger på og genstartes, vil persistenskøen blive generklæret under genstarten, og under alle omstændigheder kan kun vedvarende beskeder genoprettes.
Forbruger
Forbrugerforbrugsnyheder. I AMQP er der to måder, hvorpå forbrugere kan modtage ventende beskeder:
Beskedmiddleware leverer beskeder til forbrugerne (push API)
Forbrugere modtager aktivt beskeder (pull API)
Bemærk: Når flere forbrugere lytter til den samme kø, vil beskederne i køen kun blive optaget af én af forbrugerne (ikke én gang for hver forbruger)
Budskab
De data, der transmitteres mellem beskeder, tjenester og applikationer, består af egenskaber og kroppe.
Attributter ændrer beskeder, såsom beskedprioritet, forsinkelse og andre avancerede funktioner, og hoveddelen er indholdet af beskedens krop.
Beskedegenskaber:
- Indholdstype
- Indholdskodning
- Routingnøgle
- Leveringsmetode (vedvarende eller ej)
- Leveringsmetode (vedvarende eller ikke-persistent)
- Beskedprioritet
- Tidsstempel for meddelelsesudgivelse
- Udløbstid
- Udgivers applikations-id
Beskedens hoveddel:
Ud over attributterne indeholder AMQP-meddelelser også en payload (de data, som beskeden faktisk bærer), som behandles af AMQP-proxyen som et uigennemsigtigt byte-array.
Beskedmægleren inspicerer eller ændrer ikke nyttelasten. Beskeder kan kun indeholde attributter uden at bære en payload. Den bruger typisk data i et serialiseret format som JSON, og for at spare penge vil protokolbuffere og MessagePacks serialisere de strukturerede data til publicering som en payload af beskeder. AMQP og dets jævnaldrende bruger typisk felterne "indholdstype" og "indholdskodning" til at kommunikere med beskeder og identificere nyttelaster, men dette er kun baseret på konventioner.
Beskedens vedholdenhed:
Beskeder offentliggøres på en vedvarende måde, og AMQP-agenten gemmer denne besked på disken. Hvis serveren genstartes, bekræfter systemet, at den modtagne persistensmeddelelse ikke er tabt.
At sende en besked til en persistent switch eller dirigere den til en vedvarende kø gør ikke beskeden persistent: beskedens persistens afhænger fuldstændigt af beskedens egen persistenstilstand.
At offentliggøre beskeder på en vedvarende måde kan have en indvirkning på ydeevnen.
AMQP-arbejdsproces
Forlaget udgiver en besked gennem Exchange.
Switchen distribuerer de indkommende beskeder til køen, der er bundet til switchen i henhold til routingreglerne.
Endelig vil AMQP-agenten levere beskeden til den forbruger, der har tilmeldt sig denne kø, eller forbrugeren vil selv få den efter behov.
AMQP-beskedmekanisme
Beskedbekræftelse
Forbrugere undlader lejlighedsvis at behandle beskeder eller crasher nogle gange direkte. Og netværksårsager kan også forårsage forskellige problemer.
Dette stiller os spørgsmålet om, hvornår det er det rigtige tidspunkt for AMQP-agenter at slette beskeder.
AMQP's to beskedbekræftelsestilstande:
Auto-Confirm Mode: Slet beskeden, så snart den sendes til forbrugeren af beskedmiddleware. (Ved brug af AMQP-metoden: basic.deliver eller basic.get-ok)
Eksplicit bekræftelsestilstand: Vent på, at forbrugeren sender en bekræftelse, før du sletter beskeden. (Ved brug af AMQP-metoden: basic.ack)
Hvis en forbruger lægger på uden at sende en bekræftelseskvittering, sender AMQP-agenten beskeden videre til en anden forbruger. Hvis der ikke er nogen forbrugere tilgængelige på det tidspunkt, venter beskedmægleren på, at den næste forbruger registrerer sig i køen, og forsøger derefter at levere igen.
Afvis beskeder
Når en forbruger modtager en besked, kan behandlingsprocessen lykkes eller fejle. Forbrugeren kan angive til beskedmægleren (beskedmellemvaren), at beskeden ikke blev behandlet (eller ikke blev fuldført på dette tidspunkt) på grund af en "afvist besked".
Når en besked afvises, kan forbrugeren fortælle beskedmægleren, hvad den skal gøre med beskeden – ødelægge den eller lægge den tilbage i køen.
Når der kun er én forbruger i denne kø, skal du sørge for, at du ikke afviser beskeden og vælger at lægge den tilbage i køen, hvilket får beskeden til at gå i loop på ubestemt tid på den samme forbruger.
I AMQP bruges basic.reject-metoden til at udføre operationen med at afvise beskeder. Dog har basic.reject en begrænsning: du kan ikke bruge det til at afvise flere beskeder med anerkendelser. Men hvis du bruger RabbitMQ, kan du bruge AMQP 0-9-1-udvidelsen kaldet negative bekræftelser (også kaldet nacks) til at løse dette problem.
Oprindelig:Hyperlink-login er synlig.
|
Opslået på 14/08/2022 23.22.55
|
|
|
|
