RabbitMQ

RabbitMQ software

Tip	middleware orientat către mesaje (nu în listă )
Dezvoltator	Pivot
Ultima versiune	3.8.17 (8 iunie 2021)
Sistem de operare	Multiplatform
Limba	Erlang
Licență	Licență publică Mozilla ( licență gratuită )
Limbă	Engleză
Site-ul web	www.rabbitmq.com/
Editați datele din Wikidata · Manual

RabbitMQ este un middleware orientat către mesaje (numit și broker de mesagerie ) care implementează Protocolul avansat de așteptare a mesajelor ( AMQP ). Serverul RabbitMQ este scris în Erlang și se bazează pe cadrul Open Telecom Platform ^[1] (OTP) pentru clustering și gestionarea failover-ului. Bibliotecile client pentru interfața cu acest broker sunt disponibile pentru mai multe limbi.

Un broker de mesaje este un program intermediar care traduce un mesaj din protocolul de mesagerie formal al expeditorului în protocolul de mesagerie formal al receptorului. Brokerii de mesaje sunt elemente ale rețelelor de telecomunicații sau de computere în care aplicațiile software comunică prin schimbul de mesaje definite formal.

Istorie

"LShift și CohesiveFT au lansat RabbitMQ, o implementare completă open source a Advanced Message Queuing Protocol (AMQP), standardul emergent pentru mesaje de înaltă performanță pentru întreprinderi." ^[2]

În februarie 2007, cu aceste cuvinte, asocierea între LShift și CohesiveFT a lansat software-ul RabbitMQ pe piață, pentru a deveni rapid unul dintre cele mai populare instrumente de mesagerie asincronă ^[3] .

În aprilie 2010, a fost achiziționată de SpringSource, o divizie a VMware , care a adăugat sistemul de mesagerie deschisă RabbitMQ la suita sa de tehnologii care reduc complexitatea asociată cu dezvoltarea, implementarea și gestionarea aplicațiilor de întreprindere. Cu toate acestea, condițiile acordului nu au fost dezvăluite.

Descriere

Un broker de mesaje este un model arhitectural pentru validarea, transformarea și direcționarea mesajelor. Brokerul mediază comunicarea între aplicații, minimizând conștientizarea reciprocă, adică ce aplicații ar trebui să aibă unul față de celălalt pentru a putea face schimb de mesaje, implementând efectiv decuplarea .

Scopul principal al unui broker este de a prelua mesajele primite din aplicații și de a efectua unele acțiuni asupra acestora. De exemplu, un broker de mesaje poate fi utilizat pentru a gestiona o coadă de sarcini de lucru sau o coadă de mesaje pentru mai mulți receptori, oferind memorie fiabilă cu livrare de mesaje garantată.

În scenariul tipic al schimbului de mesaje, RabbitMQ introduce, pe lângă prezența editorului , a consumatorului și a cozii , un element nou: schimbul . Prin această modificare are loc implementarea protocolului AMQP.

Această implementare diferă de scenariul anterior definit de JMS , în care sunt prezente cele trei elemente menționate mai sus și în care se aplică o metodă de tranzit FIFO într-o singură coadă.

Cu RabbitMQ, editorul nu mai trimite mesajul direct la coadă, ci trece prin Exchange, care creează comunicarea cu coada printr-un link numit legare .

Diferența dintre RabbitMQ și JMS: Exchange este introdus în RabbitMQ pentru a media schimbul de mesaje între editor și o coadă asociată cu un anumit consumator.

RabbitMQ oferă posibilitatea de a utiliza diferite tipuri de Exchange pentru a satisface diferite nevoi. Cu toate acestea, se pot contura trei categorii principale:

Fanout
Direct
Subiect

Fiecare dintre aceste categorii definește un comportament diferit în ceea ce privește modul în care mesajul este direcționat de la Exchange la cozi. Folosind Exchange se determină un sistem numit Pub / Sub . De fapt, în realitate nu există doar un singur consumator, ci mii. Din acest motiv, mesajul publicat de editor este trimis către toate cozile abonate la un anumit Exchange referitor la editorul expeditor.

Fanout

Comportamentul schimbului în modelul Fanout

Schimbul Fanout transmite toate mesajele primite către toate cozile pe care le cunoaște.

Odată ce editorul publică un mesaj, acesta este procesat de Exchange, care îl transmite către toate cozile abonate la acesta.

Direct

Comportamentul schimbului în modelul Direct

În schimb direct, mesajul este redirecționat la cozi a căror cheie de asociere se potrivește exact cu cheia de rutare (etichetă) a mesajului. În schimbul direct este posibil să asociați cozi multiple cu aceeași cheie de asociere.

În exemplu, Q1 este legat cu cheia de legare Orange , Q2 cu Yellow și Q3 cu Orange , Black și Green .

Dacă Exchange primește mesajul cu cheia de rutare portocalie , acesta trimite mesajul către Q1 și Q3.

Dacă Exchange primește mesajul cu tasta Yellow Routing, trimite un mesaj către Q2.

În cele din urmă, dacă Exchange primește mesajul cu cheia Green Routing, acesta îl redirecționează către Q3.

Fanout VS Direct

În Fanout, mesajele sunt trimise către toate cozile care sunt conectate la Exchange fără a verifica cheia de legare cu cheia de rutare. Astfel de chei pot fi specificate în model, dar în Fanout nu afectează comportamentul Exchange. În modelul Direct, prezența cheilor este fundamentală și, mai presus de toate, potrivirea dintre cheia de rutare și cheia de legare. Exchange trimite mesaje către cozi pentru care condiția {Cheie de rutare == Cheie de legare} este validă.

Subiect

Subiectul Exchange este o sinteză a modelelor Fanout și Direct. Modelul Topic este utilizat dacă în schimbul direct există posibilitatea de a lega cheia de rutare cu cozile, dar fără posibilitatea de potrivire pe baza modelului.

În modelul Subiect, mesajele sunt direcționate către una sau mai multe cozi pe baza modelului utilizat pentru a asocia o coadă cu Exchange. Ultimul tip de schimb lasă mai multă libertate în specificarea cheilor de legare care permit utilizarea așa-numitelor metacaractere (sau metacaractere). Primul este caracterul „ * ” care înlocuiește utilizarea unui singur cuvânt în timp ce „ # ” reprezintă zero sau mai multe cuvinte.

Mesajele șablon de subiect trimise către un Exchange nu pot avea o cheie de rutare arbitrară, ci trebuie să fie o listă de cuvinte, delimitate de puncte. Exemple valide de chei de rutare sunt „ stock.usd.nyse ”, „ nyse.vmw ”, „ quick.orange.rabbit ”.

Cozile pot fi legate de Exchange folosind modele precum „ * .usd. * ”, Rezultând toate mesajele în care „ usd ” este o parte centrală a mesajului.

Exemplu de comportament în modelul Topic

Referindu-ne la imaginea care prezintă un exemplu de comportament al modelului Topic, trei cozi diferite sunt identificate prin cheia lor de legare. Dacă mesajul care ajunge la Exchange are o cheie de rutare, cum ar fi " formă ", va fi trimis la a treia coadă care respectă exact potrivirea și la a doua coadă, deoarece în modelul său există atât formă, cât și caracterul "#" , adică zero sau mai multe cuvinte. Dimpotrivă, prima coadă nu respectă potrivirea, deoarece structura cheii sale obligatorii necesită prezența a două cuvinte (dintre care unul trebuie să aibă formă ).

Dacă, pe de altă parte, cheia de rutare a fost „ shape.circle ”, mesajul este direcționat către prima și a doua coadă, dar nu către a treia, deoarece aceasta din urmă necesită prezența doar a cuvântului formă .

Pentru a obține comportamentul unui Exchange Fanout trebuie să folosim „#” simplu ca cheie de legare, care permite rutare indiferent de cheia de rutare, deoarece există întotdeauna o potrivire cu zero sau mai multe cuvinte.

RabbitMQ în centrele de date ^[4]

Un cluster RabbitMQ este un cluster ^[5] în care este necesară prezența a cel puțin două noduri Rabbit (de preferință 3). Unul dintre ele este nodul primar, iar celelalte sunt numite secundare. Clusterul RabbitMQ este utilizat deoarece oferă o disponibilitate ridicată ( HA ), adică dacă un nod eșuează, ceilalți își pot continua treaba. Toate nodurile trebuie să fie în aceeași rețea LAN , deoarece fiecare nod verifică prezența celorlalți prin verificarea bătăilor inimii . Când nodurile aparținând a două centre de date înregistrează o deconectare, se confruntă cu această problemă continuând să funcționeze independent; acest scenariu nu mai oferă beneficii de fiabilitate care existau înainte de deconectare.

În clusterul RabbitMQ, schimburile și configurațiile sunt reproduse pe toate nodurile pentru a obține HA. Fiecare nod poate fi declarat ca un nod cu disc sau cu un nod cu memorie . Este nevoie de cel puțin un nod susținut pe disc care să poată păstra informațiile și, în consecință, să garanteze o fiabilitate mai mare, în cazul unui accident pe întregul sistem. Nodurile susținute de memorie sunt mult mai rapide la replicarea datelor.

Pentru a obține un cluster HA, aveți nevoie de cozi oglindite ^[6] , care oferă o îmbunătățire față de performanțele cozilor obișnuite. Acestea din urmă se află pe nodul declarat sau creat și au o performanță mai bună în viteza de execuție / transferul mesajelor, dar sunt sensibile la timp și sunt limitate în timp . În schimb, cozile în oglindă permit duplicarea mesajelor pe toate nodurile, în detrimentul unei performanțe mai slabe / debit de mesaje. Ca rezultat, debitul întregului sistem depinde de debitul tuturor nodurilor din sistem.

Cea mai bună soluție este reprezentată de compromisul celor două scenarii analizate anterior, garantând o copie a mesajului pe toate nodurile și, prin urmare, o fiabilitate mai mare.

Exemplu ^[7]

Într-un cluster RabbitMQ HA cu echilibrare a sarcinii, unde cozile reprezintă structuri singulare, adică nu există pe mai multe noduri, apare următorul scenariu. Nodurile 1 și 3 sunt reproduse astfel încât instantaneele tuturor cozilor compatibile cu HA să fie sincronizate pe fiecare nod. Se creează o nouă coadă care, fiind Load Balancer programat în modul Round-Robin , se află pe nodul 2 și este definită ca „NewQueue” (totuși este posibil să alegeți în mod explicit nodul pe care doriți să creați coada).

Politica HA necesită să replicați coada pe toate nodurile din cluster. Pe măsură ce mesajele sunt adăugate la coadă, acestea sunt reproduse la fiecare nod. În esență, un instantaneu al cozii replicate este realizat pe fiecare nod printr-o activitate de fundal asincronă, ori de câte ori starea cozii se schimbă. Apoi, conectându-vă la RabbitMQ și indicând „NewQueue”, Load Balancer direcționează către un nod adecvat. Se poate presupune că sunteți conectat la instanța "NewQueue" care se află pe acel nod.

Cu toate acestea, acest lucru nu este cazul. De fapt, trebuie întotdeauna avut în vedere faptul că o coadă RabbitMQ este o structură singulară, adică există doar pe nodul pe care a fost creată, indiferent de politica HA. O coadă va fi întotdeauna master și va avea asociate de la 0,1, ..., N sclavi. Conform exemplului anterior, „NewQueue” a nodului 2 este coada principală, deoarece acesta este nodul pe care a fost creat, în timp ce nodurile 1 și 3 reprezintă sclavi.

Presupunând că nodul 2 „moare”, tehnic nu returnează bătăile inimii și este considerat dezagregat. În acest scenariu, coada principală "NewQueue" nu mai este disponibilă, așa că RabbitMQ promovează instanța sclavului "NewQueue" pe nodul 1 sau 3. Acest comportament evidențiază avantajele RabbitMQ în ceea ce privește fiabilitatea.

În cazul în care toate cele 3 noduri sunt în viață și instanța "NewQueue" de pe nodul 2 este masteră, revine la scenariul implicit. Când RabbitMQ se conectează, vizând „NewQueue”, Load Balancer determină un nod adecvat, prin programarea Round-Robin, de exemplu prin alegerea nodului 3. RabbitMQ redirecționează către nodul 2 (master), completând cu succes o conexiune la instanța master a „NewQueue ".

În ciuda faptului că cozile sunt reproduse pe fiecare nod, există o singură instanță disponibilă din fiecare coadă și se află pe nodul pe care a fost creat sau, în caz de eșec, pe instanța promovată ca master . RabbitMQ funcționează pentru a redirecționa către nodul master în orice caz. Aceasta înseamnă să faci un salt suplimentar de rețea pentru a ajunge la coada intenționată. În exemplul cu 3 noduri și un echilibru de încărcare uniform echilibrat, un salt de rețea suplimentar este susținut la aproximativ 66% din solicitări. Doar una din trei solicitări este direcționată către nodul corect.

Pentru a vă asigura că fiecare cerere este direcționată către nodul corect, există două posibilități:

Conectați-vă în mod explicit la nodul pe care se află coada de destinație.
Distribuiți cozile uniform pe noduri.

În primul caz, aplicația client trebuie să fie conștientă de toate nodurile din clusterul RabbitMQ și trebuie să știe unde se află fiecare coadă principală.

A doua soluție oferă un design în care cozile nu sunt conectate la noduri individuale. Revenind la exemplu, sunt instanțiate 3 cozi: „ NewQueue1 ”, „ NewQueue2 ” și „ NewQueue3 ”, fiecare pe un nod separat. Aplicația client poate implementa acum o funcție de randomizare care selectează una dintre cele trei cozi anterioare și se conectează explicit la aceasta.

Exemple

În această secțiune veți găsi un exemplu de program scris în Python pentru a trimite și primi mesaje pe o coadă.

introduce

Următorul cod stabilește o conexiune, verifică existența cozii, trimite mesajul și închide conexiunea:

 #! / usr / bin / env python
import pika
conexiune = pika . BlockingConnection ( pika . ConnectionParameters ( host = 'localhost' ))
canal = conexiune . canal ()
canal . queue_declare ( coadă = 'salut' )
canal . basic_publish ( exchange = " , routing_key = " hello " , body = " Hello World! " )
print ( „[x] A trimis„ Hello World! '” )
conexiune . închide ()

Recepţie

Următorul cod stabilește o conexiune, verifică existența cozii, primește mesajul și îl imprimă pe ecran:

 #! / usr / bin / env python
import pika
conexiune = pika . BlockingConnection ( pika . ConnectionParameters ( host = 'localhost' ))
canal = conexiune . canal ()
canal . queue_declare ( coadă = 'salut' )
print ( '[*] Se așteaptă mesajele. Pentru a ieși, apăsați CTRL + C' )
callback def ( ch , metodă , proprietăți , corp ):
    print ( "[x] a primit % r " % corp )
canal . basic_consume ( callback , queue = 'hello' , no_ack = True )
canal . start_consuming ()

Notă

^ Deschideți platforma de telecomunicații ( PDF ), la pdfs.semanticscholar.org .
^ Lansarea RabbitMQ Open Source Enterprise Messaging ( PDF ), pe rabbitmq.com .
^ Mesaje asincrone și sincrone , pe easy-lms.com .
^ fullstackmastery , la fullstackmastery.com . Adus la 25 mai 2018 (depus de „url original 25 mai 2018).
^ Maciej Rostanski; Krzysztof Grochla; Aleksander Seman, Evaluarea arhitecturilor clusterizate middleware extrem de disponibile și tolerante la defecțiuni folosind RabbitMQ .
^ RabbitMQ în acțiune: mesaje distribuite pentru toată lumea ( PDF ), la hpuwalbvt.updog.co . Adus la 25 mai 2018 (Arhivat din original la 26 mai 2018) .
^ Echilibrarea încărcării la RabbitMQ Cluster , pe insidethecpu.com .

Bibliografie

Elemente conexe

Perspective

Joern Barthel (13.09.2009). „ Noțiuni introductive despre AMQP și RabbitMQ ”

linkuri externe

Site-ul oficial , pe rabbitmq.com .
Blog oficial , pe rabbitmq.com .
RabbitMQ , pe packages.debian.org .
Depozitul sursă RabbitMQ , la github.com .

Portal IT : accesați intrările Wikipedia care se ocupă cu IT

[1] Deschideți platforma de telecomunicații ( PDF ), la pdfs.semanticscholar.org .

[2] Lansarea RabbitMQ Open Source Enterprise Messaging ( PDF ), pe rabbitmq.com .

[3] Mesaje asincrone și sincrone , pe easy-lms.com .

[4] ullstackmastery , la fullstackmastery.com . Adus la 25 mai 2018 (depus de „url original 25 mai 2018).

[5] Maciej Rostanski; Krzysztof Grochla; Aleksander Seman, Evaluarea arhitecturilor clusterizate middleware extrem de disponibile și tolerante la defecțiuni folosind RabbitMQ .

[6] RabbitMQ în acțiune: mesaje distribuite pentru toată lumea ( PDF ), la hpuwalbvt.updog.co . Adus la 25 mai 2018 (Arhivat din original la 26 mai 2018) .

[7] Echilibrarea încărcării la RabbitMQ Cluster , pe insidethecpu.com .

[1]

[2]

[3]

[4]

[5]

[6]

[7]