RabbitMQ

RabbitMQ
programvare
Sjangermeldingsorientert mellomvare  (  ulistet )
UtviklerAvgjørende
Siste versjon3.8.17 (8. juni 2021)
OperativsystemMultiplattform
SpråkErlang
TillatelseMozilla Public License
( gratis lisens )
TungeEngelsk
Nettstedwww.rabbitmq.com/

RabbitMQ er en meldingsorientert mellomvare (også kalt en meldingsmegler ) som implementerer Advanced Message Queuing Protocol ( AMQP ). RabbitMQ-serveren er skrevet i Erlang og er basert på Open Telecom Platform [1] (OTP)-rammeverket for clustering og failover-administrasjon. Klientbiblioteker for grensesnitt med denne megleren er tilgjengelig for flere språk.

En meldingsmegler er et mellomprogram som oversetter en melding fra avsenderens formelle meldingsprotokoll til mottakerens formelle meldingsprotokoll. Meldingsmeglere er elementer i telekommunikasjon eller datanettverk der programvareapplikasjoner kommuniserer ved å utveksle formelt definerte meldinger.

Historie

"LShift og CohesiveFT har lansert RabbitMQ, en komplett åpen kildekodeimplementering av Advanced Message Queuing Protocol (AMQP), den fremvoksende standarden for høyytelses bedriftsmeldinger." [2]

I februar 2007, med disse ordene, lanserte joint venture -selskapet mellom LShift og CohesiveFT RabbitMQ-programvaren på markedet, for raskt å bli et av de mest populære asynkrone meldingsverktøyene [3] .

I april 2010 ble det kjøpt opp av SpringSource, en avdeling av VMware , som la RabbitMQ åpne meldingssystem til sin pakke med teknologier som reduserer kompleksiteten knyttet til utvikling, distribusjon og administrasjon av bedriftsapplikasjoner. Vilkårene for avtalen ble imidlertid ikke offentliggjort.

Beskrivelse

En meldingsmegler er en arkitektonisk modell for å validere, transformere og rute meldinger. Megleren formidler kommunikasjon mellom applikasjoner, minimerer gjensidig bevissthet, dvs. hva applikasjoner bør ha i forhold til hverandre for å kunne utveksle meldinger, effektivt implementere frakobling .

Hovedformålet med en megler er å ta innkommende meldinger fra applikasjoner og utføre noen handlinger på dem. For eksempel kan en meldingsmegler brukes til å administrere en arbeidsbelastningskø eller en meldingskø for flere mottakere, noe som gir pålitelig lagring med garantert meldingslevering.

I det typiske scenarioet med utveksling av meldinger, introduserer RabbitMQ, i tillegg til tilstedeværelsen av utgiveren , forbrukeren og køen , et nytt element: utvekslingen . Gjennom denne modifikasjonen skjer implementeringen av AMQP-protokollen.

Denne implementeringen skiller seg fra det forrige scenariet definert av JMS , der de tre elementene nevnt ovenfor er til stede og der en FIFO -transitmetode brukes i en enkelt kø.

Med RabbitMQ sender utgiveren ikke lenger meldingen direkte til køen, men går gjennom Exchange, som skaper kommunikasjon med køen gjennom en lenke kalt binding .

RabbitMQ tilbyr muligheten til å bruke ulike typer Exchange for å tilfredsstille ulike behov. Imidlertid kan tre hovedkategorier skisseres:

Hver av disse kategoriene definerer forskjellig oppførsel med hensyn til hvordan meldingen rutes fra Exchange til køene. Ved å bruke Exchange bestemmes et system kalt Pub/Sub . Faktisk er det i virkeligheten ikke bare én forbruker, men tusenvis. Av denne grunn sendes meldingen publisert av utgiveren til alle køene som abonnerer på en bestemt utveksling knyttet til avsenderutgiveren.

Fanout

Fanout-sentralen sender alle mottatte meldinger til alle køer den kjenner.

Når utgiveren publiserer en melding, behandles den av Exchange som videresender den til alle køene som abonnerer på den.

Direkte

I direkte utveksling videresendes meldingen til køer hvis tilknytningsnøkkel samsvarer nøyaktig med meldingens rutenøkkel (etikett). I direkte utveksling er det mulig å knytte flere køer til samme tilknytningsnøkkel.

I eksemplet er Q1 bundet med bindingsnøkkelen Orange , Q2 med Yellow og Q3 med Orange , Black and Green .

Hvis Exchange mottar meldingen med den oransje rutenøkkelen , sender den meldingen til Q1 og Q3.

Hvis sentralen mottar meldingen med den gule rutenøkkelen , sender den en melding til Q2.

Til slutt, hvis sentralen mottar meldingen med den grønne rutingnøkkelen, videresender den den til Q3.

Fanout VS Direct

I Fanout sendes meldinger til alle køer som er knyttet til Exchange uten å sjekke bindingsnøkkelen mot routingnøkkelen. Slike nøkler kan spesifiseres i modellen, men i Fanout påvirker de ikke børsens oppførsel. I Direct-modellen er tilstedeværelsen av nøklene grunnleggende og fremfor alt samsvaret mellom rutenøkkelen og bindingsnøkkelen. Utvekslingen sender meldinger til køer der betingelsen {Routing Key == Binding Key} er gyldig.

Emne

Exchange Topic er en syntese av Fanout- og Direct-modellene. Topic-modellen brukes dersom det i direkte bytte er mulighet for å binde rutenøkkelen med køene, men uten mulighet for matching basert på modellen.

I Topic-modellen rutes meldinger til én eller flere køer basert på modellen som brukes til å knytte en kø til Exchange. Den siste typen utveksling gir større frihet til å spesifisere bindingsnøklene som tillater bruk av såkalte jokertegn (eller jokertegn). Det første er tegnet " * " som erstatter bruken av et enkelt ord mens " # " representerer null eller flere ord.

Emnemalmeldinger som sendes til en Exchange kan ikke ha en vilkårlig rutenøkkel, men må være en liste med ord, avgrenset med prikker. Gyldige eksempler på rutenøkler er " stock.usd.nyse ", " nyse.vmw ", " quick.orange.rabbit ".

Køer kan kobles til Exchange ved hjelp av mønstre som " * .usd. * ", noe som resulterer i alle meldinger hvor " usd " er en sentral del av meldingen.

Med henvisning til bildet som viser et eksempel på atferden til Topic-modellen, identifiseres tre forskjellige køer med deres bindingsnøkkel. Hvis meldingen som kommer til sentralen har en rutenøkkel som " shape ", vil den bli sendt til den tredje køen som nøyaktig respekterer matchingen og til den andre køen siden det i mønsteret er både form og "#"-tegnet , det er null eller flere ord. Tvert imot, den første halen respekterer ikke samsvaret siden strukturen til dens bindingsnøkkel krever tilstedeværelse av to ord (hvorav det ene må være form ).

Hvis på den annen side Ruting-nøkkelen var " shape.circle ", blir meldingen rutet mot den første og andre køen, men ikke i den tredje, siden sistnevnte krever tilstedeværelsen av bare ordformen .

For å få oppførselen til en Exchange Fanout må vi bruke den enkle "#" som bindende nøkkel, som tillater ruting uavhengig av rutingnøkkelen siden det alltid er matching med null eller flere ord.

RabbitMQ i datasentre [4]

En RabbitMQ-klynge er en klynge [5] der det kreves tilstedeværelse av minst to Rabbit-noder (helst 3). En av dem er den primære noden og de andre kalles sekundær. RabbitMQ-klyngen brukes fordi den gir høy tilgjengelighet ( HA ), noe som betyr at hvis en node svikter, kan de andre fortsette å gjøre jobben sin. Alle noder må være i samme LAN , siden hver node sjekker tilstedeværelsen av de andre ved å sjekke hjerteslag . Når nodene som tilhører to datasentre registrerer en frakobling, møter de dette problemet ved å fortsette å operere uavhengig; dette scenariet gir ikke lenger pålitelighetsfordelene som eksisterte før frakobling.

I RabbitMQ-klyngen replikeres utvekslinger og konfigurasjoner på alle noder for å oppnå HA. Hver node kan erklæres som en diskstøttet node eller minnestøttet node . Det er behov for minst én diskstøttet node som kan, ved en eventuell krasj på hele systemet, beholde informasjonen og derfor garantere større pålitelighet. Minnestøttede noder er mye raskere til å replikere data.

For å få en HA-klynge trenger du Mirrored Queues [6] , som tilbyr en forbedring i forhold til ytelsen til Regular Queue. Sistnevnte ligger på den deklarerte eller opprettede noden og har bedre ytelse i utførelseshastighet / meldingsgjennomstrømning, men er tidssensitive og tidsbegrensede . Omvendt tillater speilvendte køer duplisering av meldinger på tvers av alle noder, på bekostning av dårligere ytelse / meldingsgjennomstrømning. Som et resultat avhenger gjennomstrømningen til hele systemet av gjennomstrømningen til alle noder i systemet.

Den beste løsningen er representert ved avveiningen av de to scenariene som er analysert tidligere, og garanterer en kopi av meldingen på alle noder og dermed større pålitelighet.

Eksempel [7]

I en RabbitMQ HA-klynge med lastbalansering, der køene representerer entallsstrukturer, det vil si at de ikke eksisterer på mer enn én node, har vi følgende scenario. Node 1 og 3 er replikert slik at øyeblikksbilder av alle HA-kompatible køer synkroniseres på hver node. Det opprettes en ny kø som, ettersom Load Balancer er planlagt i Round-Robin- modus , ligger på node 2 og er definert som "NewQueue" (men det er mulig å eksplisitt velge noden du vil opprette køen på).

HA-policyen krever at du replikerer køen på alle noder i klyngen. Etter hvert som meldinger legges til i køen, blir de replikert til hver node. I hovedsak blir et øyeblikksbilde av den replikerte køen tatt på hver node gjennom en asynkron bakgrunnsoppgave, når køtilstanden endres. Deretter kobler du til RabbitMQ og peker på "NewQueue", leder Load Balancer til en passende node. Det kan antas at du er koblet til "NewQueue"-forekomsten som ligger på den noden.

Dette er imidlertid ikke tilfelle. Faktisk må det alltid huskes at en RabbitMQ-kø er en singular struktur, det vil si at den eksisterer bare på noden den ble opprettet på, uavhengig av HA-policyen. En kø vil alltid være master og vil ha assosiert fra 0,1, ..., N slaver. I følge eksemplet ovenfor er node 2s "NewQueue" masterkøen, da dette er noden den ble opprettet på, mens nodene 1 og 3 representerer slavene.

Forutsatt at node 2 "dør", returnerer den teknisk sett ikke et hjerteslag og regnes som disaggregert. I dette scenariet er ikke masterkøen "NewQueue" lenger tilgjengelig, så RabbitMQ promoterer forekomsten av slaven "NewQueue" på node 1 eller 3. Denne oppførselen fremhever fordelene med RabbitMQ når det gjelder pålitelighet.

I tilfelle alle 3 nodene er i live og "NewQueue"-forekomsten på node 2 er master, går den tilbake til standardscenarioet. Når RabbitMQ kobler seg til, målrettet mot "NewQueue", bestemmer Load Balancer en passende node, gjennom Round-Robin-planlegging, for eksempel ved å velge node 3. RabbitMQ omdirigerer til node 2 (master), og fullfører en vellykket kobling til hovedforekomsten av "NewQueue" ".

Til tross for at køene er replikert på hver node, er det bare én tilgjengelig forekomst av hver kø, og den ligger på noden den ble opprettet på, eller, i tilfelle feil, på forekomsten som markedsføres som master . RabbitMQ opererer for å omdirigere til masternoden i alle fall. Dette betyr å gjøre et ekstra nettverkshopp for å nå den tiltenkte køen. I eksemplet med 3 noder og en jevnt balansert belastningsbalanser opprettholdes et ekstra nettverkshopp på omtrent 66 % av forespørslene. Bare én av tre forespørsler sendes til riktig node.

For å sikre at hver forespørsel blir rutet til riktig node, er det to muligheter:

  1. Koble eksplisitt til noden som målkøen er plassert på.
  2. Fordel halene jevnt over nodene.

I det første tilfellet må klientapplikasjonen være klar over alle noder i RabbitMQ-klyngen og må vite hvor hver hovedkø er plassert.

Den andre løsningen tilbyr et design der køene ikke er koblet til individuelle noder. For å gå tilbake til eksemplet, blir 3 køer instansiert: " NewQueue1 ", " NewQueue2 " og " NewQueue3 ", hver på en separat node. Klientapplikasjonen kan nå implementere en randomiseringsfunksjon som velger en av de tre foregående køene og kobler eksplisitt til den.

Eksempler

I denne delen finner du et eksempel på et program skrevet i Python for å sende og motta meldinger i en kø.

Skriv inn

Følgende kode oppretter en forbindelse, sjekker om køen eksisterer, sender meldingen og lukker forbindelsen:

#! / usr / bin / env python import pika- tilkobling = pika . BlockingConnection ( pika . ConnectionParameters ( vert = 'localhost' )) kanal = tilkobling . kanal () kanal . queue_declare ( queue = 'hei' ) kanal . basic_publish ( exchange = '' , routing_key = 'hei' , body = 'Hello World!' ) print ( "[x] Sendt 'Hello World!'" ) tilkobling . lukk ()

Mottak

Følgende kode oppretter en forbindelse, sjekker om køen finnes, mottar meldingen og skriver den ut på skjermen:

#! / usr / bin / env python import pika tilkobling = pika . BlockingConnection ( pika . ConnectionParameters ( vert = 'localhost' )) kanal = tilkobling . kanal () kanal . queue_declare ( queue = 'hei' ) print ( '[*] Venter på meldinger. For å avslutte trykk CTRL + C' ) def callback ( ch , metode , egenskaper , body ): print ( "[x] Mottatt % r " % body ) kanal . basic_consume ( callback , queue = 'hei' , no_ack = True ) kanal . start_consuming ()

Merknader

  1. ^ Åpen telekomplattform ( PDF ), på pdfs.semanticscholar.org . Hentet 28. mai 2018 (arkivert fra originalen 29. mai 2018) .
  2. ^ Lansering av RabbitMQ Open Source Enterprise Messaging ( PDF ), på rabbitmq.com .
  3. ^ Asynkron og synkron meldinger , på easy-lms.com .
  4. ^ fullstackmastery , på fullstackmastery.com . Hentet 25. mai 2018 (Arkiveret fra originalen 25. mai 2018) .
  5. ^ Maciej Rostanski; Krzysztof Grochla; Aleksander Seman, Evaluering av svært tilgjengelige og feiltolerante mellomvare-klyngearkitekturer ved bruk av RabbitMQ .
  6. ^ RabbitMQ in Action: Distribuert meldinger for alle ( PDF ), på hpuwalbvt.updog.co . Hentet 25. mai 2018 (arkivert fra originalen 26. mai 2018) .
  7. ^ Lastbalansering på RabbitMQ Cluster , på insidethecpu.com .

Bibliografi

Relaterte elementer

Innsikt

Eksterne lenker