Introduksjon til AMQP-protokollen
AMQP (Advanced Message Queuing Protocol) er en applikasjonslagsstandardprotokoll som tilbyr enhetlige meldingstjenester, og er en åpen standard for applikasjonslagsprotokoller designet for meldingsorientert mellomvare. AMQP er en nettverksprotokoll for overføring av asynkrone meldinger mellom prosesser.
Klienter og meldingsmellomvare basert på denne protokollen kan levere meldinger uten å være begrenset av ulike klient-/mellomvareprodukter, ulike utviklingsspråk osv.
Hovedegenskapene til AMQP er meldingsorientert, købasert, ruting (inkludert peer-to-peer og publish/subscribe), pålitelighet og sikkerhet. AMQP håndhever oppførselen til meldingsleverandører og klienter, og muliggjør ekte interoperabilitet mellom ulike leverandører.
AMQP og JMS
JMS var et forsøk på å standardisere tidlig meldingsmellomvare, det var kun standardisert på API-nivå, og det var langt fra å skape interoperabilitet.
I motsetning til JMS er AMQP en trådnivåprotokoll som beskriver formatet på data som overføres over et nettverk, flytende i bytes. Som et resultat er ethvert verktøy som følger dette dataformatet, som lager og tolker meldinger, interoperabelt med andre kompatible verktøy.
AMQP-kjernesammensetning
Produsent
Produksjonsnyheter.
ConnectionFactory
Fabrikken som produserer Connection.
Forbindelse
Tilkobling, applikasjonsnettverkstilkobling med Broker TCP/IP/Triple Handshake og Quad Wave.
AMQP-tilkoblinger er vanligvis lange forbindelser. AMQP er en applikasjonslagsprotokoll som bruker TCP for å sikre pålitelig levering. AMQP bruker autentiseringsmekanismer og gir TLS (SSL)-beskyttelse. Når en applikasjon ikke lenger trenger å koble til AMQP-proxyen, må den smidig frigjøre AMQP-tilkoblingen i stedet for bare å slå av TCP-tilkoblingen.
Kanal
Nettverkskanalen er en lettvektstilkobling bygget oppå tilkoblingen. Nesten alle operasjoner utføres i kanaler, som er kanaler for å lese og skrive meldinger, og klienter kan etablere par for hver kanal, hvor hver av dem representerer en sesjonsoppgave.
Hvis tilkoblingen sammenlignes med en fiberoptisk kabel, sammenlignes kanalkanalen med en av fibrene i en fiberoptisk kabel. Et hvilket som helst antall kanaler kan opprettes på en tilkobling.
De fleste av våre forretningsoperasjoner foregår i kanalgrensesnittet, inkludert:
- queueDeclare
- ExchangeDeclar for svitsjen
- queueBind queueBind
- Publiser meldingen basicPublish
- Forbrukernyheter, grunnforbruk, osv.
Megler
Aksepter klientens tilkobling for å implementere AMQP-entitetstjenester, som rabbitmq.
VirtualHost (webhotell)
Virtuell hosting, brukt til logisk isolasjon, en virtuell vert kan ha flere utvekslinger og køer, og den samme virtuelle verten kan ikke ha utvekslinger med samme navn.
For å implementere flere isolerte miljøer (brukere, brukergrupper, svitsjer, køer osv.) på en enkelt proxy, tilbyr AMQP konseptet virtuelle verter (virtuelle verter – vhosts). Dette ligner veldig på webserverens webhotellkonsept, som gir et helt isolert miljø for AMQP-enheter. Når tilkoblingen er etablert, spesifiserer AMQP-klienten hvilken virtuell vert som skal brukes.
Utveksling
Switchen tar imot meldinger, og sender meldinger til den bundne køen basert på rutingnøkkelen (uten mulighet for meldingslagring).
En switch er en AMQP-enhet som brukes til å sende meldinger. Etter at switchen får en melding, ruter den den til én eller null køer. Routing-algoritmen den bruker bestemmes av brytertypen og bindingsreglene.
Brytertype:
- Direkte utveksling
- Utveksling av utslag
- Temautveksling
- Headers-utveksling
Switch-egenskaper:
- Navn: Navnet på bryteren
- Holdbarhet: Et persistensflagg som indikerer om denne bryteren er bevart eller ikke
- Auto-sletting: Slett-flagg, indikererNår alle køer er ferdige med denne utvekslingen, om de slettes
- Argumenter: Avhengig av agenten selv
Bryterstatus:
Vedvarende svitsjer vil eksistere etter at megleren er startet på nytt, mens staging-svitsjer ikke vil eksistere (de må erklæres på nytt etter at megleren er tilbake online).
Standardbryter
Standardutvekslingen er faktisk en direkte utveksling som er forhåndsdeklarert av meldingsmegleren og har ikke noe navn (navnet er en tom streng).
Du kan tenke på standardbryteren som en spesiell direktekoblet bryter.
Standard bryternavn: Null-streng (AMQP standard)
Standard brytertype: Direktekoblet bryter
Når man oppretter en kø, så lenge svitsjen som skal bindes ikke er spesifisert, vil den automatisk være bundet til standardbryteren, og rutingnøkkelnavnet til bindingen vil være det samme som kønavnet.
Direkte tilkobling til bryteren
En direktekoblet svitsj leverer meldinger til en kø av tilsvarende bindingsnøkler basert på rutingnøkkelen som meldingen bærer. Unicast-rutingen som brukes av den direkte bryteren for å håndtere meldingen.
Når man oppretter en kø, hvis den er bundet til en direkte svitsj, trenger den ikke å spesifisere navnet på rutingnøkkelen, fordi den vil ha et standard rutingnøkkelnavn, som er det samme som køens navn.
En kø med direktetilkoblede svitsjer distribuerer vanligvis oppgaver til flere brukere i en sløyfe (vi kaller dette polling).
Arbeidsflyt:
- Når du binder en kø til en bryter, gi den en bindingsnøkkel, forutsatt R;
- Når en melding med en rutingnøkkel sendes til en direkte tilknyttet svitsj, ruter svitsjen den til en kø med en rutingnøkkel.
Viftebrytere
Viftebryteren sender meldinger til alle køer knyttet til den, uavhengig av den bundne rutingnøkkelen.
Hvis N køer er bundet til en sektorsvitsj, sender svitsjen en kopi av meldingen til alle N køer separat når en melding sendes til denne sektorsvitsjen. Viftebrytere brukes vanligvis til å håndtere kringkastingsruting av meldinger.
Bruksscenarier:
kringkastingsmeldinger;
Gruppechat-funksjon.
Tema-bytte
Emnebyttet sender meldinger til en eller flere køer i henhold til rutingnøkkelen og typen Exchange, og vi bruker det ofte til å implementere ulike publiser/abonnere, altså publiser-abonnementer.
Routingreglene for direkte tilknyttede svitsjer er strengt matchet, noe som betyr at rutingnøkkelen må matche bindingsnøkkelen før en melding sendes til køen.
Routingreglene for emnebyttet er fuzzy-matcher som kan leveres ved å oppfylle noen av reglene gjennom jokerkort.
Den fastslår:
- Det kan være to spesialtegn * og # i bindingstasten for fuzzy matching. hvor * brukes for å matche et ord, #用于匹配多个单词 (kan være null)
- En rutingnøkkel er en prikkseparert streng (vi kaller hver enkelt streng adskilt av en prikk for et ord)
- Når produsenten sender meldingen Routing Key=A.A.A, er kun A.*.* tilfredsstilt, og den vil kun bli rutet til kø1.
- Når produsenten sender meldingen Routing Key=A.B.A, vil tilfredsstillelsen A.*.* og *.B.* bli rutet til kø1 og kø2.
- Når produsenten sender meldingen Routing Key=A.B.C, er A.*.* og *.B.* og *.* tilfredsstilt. C rutes til kø1, kø2, kø3.
Bruksscenarier:
- nyhetsoppdateringer med kategorier eller tagger;
- Bakgrunnsoppgaver utført av flere arbeidere, som hver har ansvar for å håndtere bestemte oppgaver.
Hodebryter
Headers-svitsjer er ikke avhengige av matchingsreglene til rutingnøkkelen for å binde nøkler til ruting av meldinger, men matcher basert på headers-attributtet i innholdet i den sendte meldingen.
Hodebrytere kan betraktes som en annen manifestasjon av en direktekoblet bryter. Imidlertid må rutingnøkkelen til en direkte switch være en streng, og header-attributtverdiene er ikke begrenset av dette, de kan til og med være heltall eller hash-verdier (ordbøker), osv. Mer fleksibilitet (men i praksis bruker vi sjelden hodebrytere).
Arbeidsflyt:
- Når en kø er bundet til en header-switch, er flere headere bundet samtidig for matching.
- Innkommende meldinger bærer en header og en "x-match"-parameter. Når "x-match" settes til "any", kan hvilken som helst verdi i headeren matches, og når "x-match" settes til "alle", må alle verdier i headeren matches.
Bryteroppsummering
Binding
Virtuell forbindelse mellom Exchange og Queue.
BindingKey er en regelbeskrivelse for Exchange og Queue-bindings. Bindingsnøkkelen spesifiserer hvilken type rutingnøkkel som skal tildeles den for øyeblikket bundne køen under den nåværende utvekslingen.
Rutingnøkkel
Routingregler, som den virtuelle maskinen kan bruke for å bestemme hvordan en bestemt melding skal rutes.
Bindingsnøkkel vs. rutingnøkkel
- Bindingsnøkkelen er bindingsnøkkelen mellom køen og bryteren;
- Routing Key er en informasjonsbit som produsenten sender til switchen;
- Når bindingsnøkkelen og rutingnøkkelen samsvarer, legg meldingen i den tilsvarende køen.
Binding Key er regelbeskrivelsen for Exchange og Queue-binding, som brukes til å analysere når Exchange mottar en melding, meldingen mottatt av Exchange vil ha et rutingnøkkelfelt, og Exchange matcher denne rutingnøkkelen med alle bindingsnøkler i den nåværende Exchange, og hvis kravene er oppfylt, vil den bli sendt til Binding Nøkkelen er bundet til køen for å sende meldingen.
Bindingsnøkkel vs. rutingnøkkel i ulike brytere
Standardbryter: Binding Key er køens navn, som ikke kan tilpasses. Routingnøkkelen er også køens navn før den kan rutes til køen
Direkte tilkoblingsbryter: Binding Key er navnet på køen, som kan tilpasses. Routingnøkler kan bare rutes vellykket til køen når bindingsnøkkelen er den samme
Viftebryter: Ingen bindenøkkel; Selvfølgelig finnes det ingen rutingnøkkel. Automatisk rutet til alle køer bundet til svitsjen
Tema-bytte: egendefinert bindingsnøkkel; Tilpass rutingnøkkelen. Routing Key==Bindingsnøkkel, og fuzzy-matchen må rutes vellykket til køen
Hodebryter: ingen bindenøkkel; Selvfølgelig finnes det ingen rutingnøkkel. Matcher basert på header-attributten i innholdet i meldingen som sendes
Kø
Lagrer meldinger som er i ferd med å bli konsumert av appen.
Køegenskaper:
- Navn: Navnet på køen
- Holdbar: Køen eksisterer fortsatt etter at meldingsmegleren er startet på nytt
- Eksklusiv: Brukes kun av én tilkobling, og køen slettes når forbindelsen lukkes
- Auto-sletting: Slettet når siste forbruker avslutter abonnementet
- Argumenter: Noen meldingsmeglere bruker det til å utføre noen ekstra funksjoner som ligner på TTL
Opprettelse av kø:
Køer kan kun brukes etter at de er erklært. Hvis en kø ikke allerede eksisterer, opprettes den ved å erklære en kø. Hvis den deklarerte køen allerede eksisterer og attributtene er identiske, har deklarasjonen ingen effekt på den opprinnelige køen. Hvis attributtene i deklarasjonen skiller seg fra de i den eksisterende køen, kastes et kanalnivå-unntak med feilkode 406.
Køpersistens:
Persistenskøen lagres på disk og forblir der når megleren startes på nytt. Køer som ikke opprettholdes, kalles transiente køer. Ikke alle scenarioer og tilfeller krever køpersistens.
En vedvarende kø gjør ikke meldinger som rutes til den persistente. Hvis meldingsagenten legger på og startes på nytt, vil persistenskøen bli erklært på nytt under omstarten, og uansett kan kun vedvarende meldinger gjenopprettes.
Forbruker
Forbrukernyheter. I AMQP finnes det to måter for forbrukere å få ventende meldinger på:
Meldingsmellomware leverer meldinger til forbrukere (push API)
Forbrukere mottar aktivt meldinger (pull API)
Merk: Når flere forbrukere lytter til samme kø, vil meldingene i køen kun bli konsumert av én av forbrukerne (ikke én gang per forbruker)
Budskap
Dataene som overføres mellom meldinger, tjenester og applikasjoner består av egenskaper og kropper.
Attributter endrer meldinger, som meldingsprioritet, forsinkelse og andre avanserte funksjoner, og hoveddelen er innholdet i meldingsdelen.
Meldingsegenskaper:
- Innholdstype
- Innholdskoding
- Routingnøkkel
- Leveringsmåte (vedvarende eller ikke)
- Leveringsmodus (vedvarende eller ikke-persistent)
- Meldingsprioritet
- Tidsstempel for meldingspublisering
- Utløpstid
- Utgivers applikasjons-ID
Meldingens hoveddel:
I tillegg til attributtene inneholder AMQP-meldinger også en nyttelast (dataene meldingen faktisk bærer), som behandles av AMQP-proxyen som et ugjennomsiktig bytearray.
Meldingsmegleren inspiserer eller endrer ikke nyttelasten. Meldinger kan kun inneholde attributter uten å bære en nyttelast. Den bruker vanligvis data i et serialisert format som JSON, og for å spare penger vil protokollbuffere og MessagePacks serialisere de strukturerte dataene for publisering som en nyttelast av meldinger. AMQP og dets jevnaldrende bruker vanligvis feltene «innholdstype» og «innholdskoding» for å kommunisere med meldinger for å identifisere nyttelaster, men dette er kun basert på konvensjoner.
Meldingspersistens:
Meldinger publiseres på en vedvarende måte, og AMQP-agenten lagrer denne meldingen på disk. Hvis serveren startes på nytt, bekrefter systemet at persistensmeldingen ikke er tapt.
Å bare sende en melding til en persistent switch eller rute den til en vedvarende kø gjør ikke meldingen persistent: persistensen til meldingen avhenger helt av selve meldingens persistensmodus.
Å publisere meldinger på en vedvarende måte kan ha en effekt på ytelsen.
AMQP-arbeidsprosess
Forlaget publiserer en melding gjennom Exchange.
Svitsjen distribuerer de innkommende meldingene til køen som er bundet til svitsjen i henhold til rutingsreglene.
Til slutt vil AMQP-agenten levere meldingen til forbrukeren som har abonnert på denne køen, eller forbrukeren henter den selv etter behov.
AMQP-meldingsmekanisme
Meldingsbekreftelse
Forbrukere klarer av og til ikke å behandle meldinger eller krasjer noen ganger direkte. Og nettverksårsaker kan også forårsake ulike problemer.
Dette stiller oss spørsmålet om når det er riktig tidspunkt for AMQP-agenter å slette meldinger.
AMQPs to meldingsbekreftelsesmoduser:
Auto-Confirm Mode: Slett meldingen så snart den sendes til forbrukeren av meldingsmellomvaren. (Ved bruk av AMQP-metoden: basic.deliver eller basic.get-ok)
Eksplisitt bekreftelsesmodus: Vent på at forbrukeren sender en bekreftelse før du sletter meldingen. (Ved bruk av AMQP-metoden: basic.ack)
Hvis en forbruker legger på uten å sende bekreftelseskvittering, leverer AMQP-agenten meldingen videre til en annen forbruker. Hvis det ikke er noen tilgjengelige forbrukere på det tidspunktet, venter meldingsmegleren på at neste forbruker skal registrere seg i denne køen, og prøver deretter å levere igjen.
Avvis meldinger
Når en forbruker mottar en melding, kan behandlingsprosessen lykkes eller feile. Forbrukeren kan indikere til meldingsmegleren (meldingsmellomvare) at meldingen ikke ble behandlet (eller ikke fullført på dette tidspunktet) på grunn av en "avvist melding".
Når en melding blir avvist, kan forbrukeren fortelle meldingsmegleren hva de skal gjøre med meldingen – ødelegge den eller legge den tilbake i køen.
Når det bare er én forbruker i denne køen, sørg for at du ikke avviser meldingen og velger å legge den tilbake i køen, noe som får meldingen til å gå i loop uendelig på samme forbruker.
I AMQP brukes metoden basic.reject for å utføre operasjonen med å avvise meldinger. Likevel har basic.reject en begrensning: du kan ikke bruke det til å avvise flere meldinger med bekreftelser. Men hvis du bruker RabbitMQ, kan du bruke AMQP 0-9-1-utvidelsen kalt negative acknowledgements (også kalt nacks) for å løse dette problemet.
Original:Innloggingen med hyperkoblingen er synlig.
|
Publisert på 14.08.2022 23:22:55
|
|
|
|
