RabbitMQ: differenze tra le versioni

Versione delle 19:49, 26 mag 2018

Versione attuale delle 11:14, 22 mar 2025

(39 versioni intermedie di 19 utenti non mostrate)

Riga 1:

{{F|software|luglio 2017}}

{{Software

|Nome = RabbitMQ

Line 6 ⟶ 5:

|Didascalia =

|Sviluppatore = [[Pivotal]]

|UltimaVersione = 3.6.9

|DataUltimaVersione = {{Data e tempo|2017|03|29}}

|UltimaVersioneBeta =

|DataUltimaVersioneBeta =

Line 16 ⟶ 15:

|Lingua = Inglese

}}

'''RabbitMQ''' è un [[message-oriented middleware]] (detto anche [[broker di messaggistica]]) che implementa il protocollo [[Advanced Message Queuing Protocol]] ('''AMQP'''). Il server RabbitMQ è scritto in [[Erlang (linguaggio di programmazione)|Erlang]] e si basa sul [[framework]] Open Telecom Platform<ref>{{Cita web|url=https://pdfs.semanticscholar.org/af89/dc63c4491b430a3de659e364ed28f5685840.pdf|titolo=Open telecom platform|accesso=28 maggio 2018|dataarchivio=29 maggio 2018|urlarchivio=https://web.archive.org/web/20180529130025/https://pdfs.semanticscholar.org/af89/dc63c4491b430a3de659e364ed28f5685840.pdf|urlmorto=sì}}</ref> (OTP) per la gestione del [[clustering]] e del [[failover]]. Le librerie client per interfacciarsi a questo broker sono disponibili per diversi linguaggi.

Il server RabbitMQ è scritto in [[Erlang (linguaggio di programmazione)|Erlang]] e si basa sul framework '''Open Telecom Platform''' (OTP) per la gestione del clustering e del failover.

Le librerie client per interfacciarsi a questo broker sono disponibili per diversi linguaggi.

Un ''[[:en:Message_broker|broker di messaggi]]'' è un programma intermedio che traduce un messaggio dal protocollo di messaggistica formale del mittente al protocollo di messaggistica formale del ricevitore. I broker di messaggi sono elementi di telecomunicazione o reti di computer in cui le applicazioni software comunicano scambiando messaggi definiti in modo formale.

== Storia ==

''“LShift and CohesiveFT have launched RabbitMQ, a complete open source implementation of Advanced Message Queuing Protocol (AMQP), the emerging standard for high performance enterprise messaging.”''<ref>{{Cita web|url=https://www.rabbitmq.com/resources/RabbitMQ_PressRelease_080207.pdf|titolo=Launch of RabbitMQ Open Source Enterprise Messaging}}</ref>

Nel Febbraio 2007  con queste parole la [[joint venture]] tra [https://tech.labs.oliverwyman.com/ LShift] {{Webarchive|url=https://web.archive.org/web/20180524003603/https://tech.labs.oliverwyman.com/ |date=24 maggio 2018 }} e CohesiveFT lanciò sul mercato il software RabbitMQ, per divenire in poco tempo tra i più popolari strumenti di messaggistica asincrona<ref>{{Cita web|url=https://www.easy-lms.com/it/aiuto/centro-di-conoscenza-lms/apprendimento-sincrono-vs-asincrono/item10387|titolo=Messagistica asincrona e sincrona}}</ref>.

Nell'aprile 2010 è stata acquistata da SpringSource, una divisione di [[VMware Inc.|VMware]], che ha aggiunto il sistema di messaggistica aperta RabbitMQ nella sua suite di tecnologie che riducono la complessità associata allo sviluppo, all'implementazione e alla gestione delle applicazioni aziendali. Tuttavia i termini dell'accordo non sono stati divulgati.

== Descrizione ==

Un broker di messaggi è un modello architettonicoarchitetturale per la convalida, la trasformazione e il routing dei messaggi. Il broker media la comunicazione tra le applicazioni, riducendo al minimo la consapevolezza reciproca, ovvero quella che le applicazioni dovrebbero avere l'una rispetto all'altra al fine di poter scambiare messaggi, implementando in modo efficace il [[disaccoppiamento]].

Lo scopo principale di un broker è di prendere i messaggi in arrivo dalle applicazioni ed eseguire alcune azioni su di essi. Ad esempio, un broker di messaggi può essere utilizzato per gestire una coda di carico di lavoro o una coda di messaggi per più ricevitori, fornendo memoria affidabile, con una consegna di messaggi garantita.

Nel tipico scenario dello scambio di messaggi, RabbitMQ introduce, oltre la presenza del '''Publisher''', del '''Consumer''' e della '''Queue''', un nuovo elemento: l’'''Exchange'''l’Exchange. Attraverso questa modifica avviene l’implementazione del protocollo AMPQAMQP.

Tale implementazione differisce dal precedente scenario definito dal [[Java Message Service|JMS]], nel quale si ha la presenza dei tre elementi sopracitati ed in cui si applica un metodo di transito [[FIFO]] in una singola coda.

Con RabbitMQ il Publisher non invia più il messaggio direttamente alla coda, ma passa per l’Exchange, il quale crea la comunicazione con la coda attraverso un legame detto '''binding'''.

[[File:Esempio_di_funzionamento_RabbitMQ.png|miniatura|Differenza tra RabbitMQ e JMS: nel RabbitMQ viene introdotto l'Exchange, per mediare lo scambio di messaggi tra il Publisher e una coda, associata ad uno specifico consumatore.|290x290px310x310px]]

RabbitMQ offre la possibilità di utilizzare diversi tipi di '''Exchange''' al fine di soddisfare i differenti bisogni. Tuttavia si possono delineare tre principali categorie:

RabbitMQ offre la possibilità di utilizzare diversi tipi di '''Exchange''' al fine di soddisfare i differenti bisogni. Tuttavia si possono delineare tre principali categorie:

* Fanout

Line 49 ⟶ 44:

* Topic

Ognuna di queste categorie definisce un diverso comportamento rispetto a come viene indirizzato il messaggio dall’Exchange alle code. Utilizzando l’Exchange viene a determinarsi un sistema definito '''[[Publish/subscribe|Pub/Sub]]'''. Infatti nella realtà non è presente un solo consumatore, bensì migliaia. Per questo motivo il messaggio pubblicato dal Publisher viene inviato a tutte le code sottoscritte ad uno specifico Exchange relativo al Publisher mittente.

=== Fanout ===

[[File:Fanout_model.png|miniatura|260x260px330x330px|Comportamento dell'Exchange nel modello Fanout]]

Lo scambio Fanout trasmette tutti i messaggi ricevuti a tutte le code che conosce.

Una volta che il Publisher pubblica un messaggio, questo viene lavorato dall’Exchange che lo inoltra a tutte le code sottoscritte a lui.

=== Direct ===

[[File:Direct_model.png|miniatura|270x270px330x330px|Comportamento dell'Exchange nel modello Direct]]

Nello scambio diretto, il messaggio viene inoltrato alle code la cui chiave di associazione corrisponde esattamente alla '''chiave di Routing''' (etichetta) del messaggio. Nello scambio diretto è possibile associare più code con la stessa chiave di associazione.

Nell'esempio, Q1 e Q2 sonoè vincolativincolato con la chiave di binding ''Orange'', Q3Q2 con ''Yellow'' e Q4Q3 con ''Orange'', ''Black'' e ''Green''.

Se l’Exchange riceve il messaggio con la chiave di Routing ''Orange'', invia il messaggio a Q1 e Q4Q3.

Se l’Exchange riceve il messaggio con la chiave di Routing ''Yellow'', invia un messaggio a Q3Q2.

Infine se l’Exchange riceve il messaggio con la chiave di Routing ''Green'' lo inoltra a Q4Q3.

==== Fanout VS Direct ====

Nel Fanout i messaggi vengono inviati a tutte le code che sono legate all'Exchange senza verificare le chiavechiavi di legame (binding key) rispetto alla chiave di instradamento (routing key). Tali chiavi possono essere specificate nel modello, ma nel Fanout non influenzano il comportamento dell’Exchange. Nel modello Direct è fondamentale la presenza delle chiavi e soprattutto il matching fra la chiave di instradamento e la chiave di legame. L’Exchange invia i messaggi alle code per cui è valida la condizione {Routing Key == Binding Key}.

=== Topic ===

L'Exchange Topic è una sintesi dei modelli Fanout e Direct. Viene usato il modello Topic se nello scambio diretto vi è la possibilità di legare la chiave di instradamento con le code, ma senza la possibilità di effettuare associazioni (matching) in base al modello.

Nel modello Topic si instradano i messaggi verso una o più code in base al modello utilizzato per associare una coda all'Exchange. Quest’ultimo tipo di scambio lascia maggiore libertà nello specificare le chiavi di legame permettendo l’utilizzo dei cosiddetti jolly (o wildcards). Il primo è il carattere "'''*"'''" che sostituisce l’utilizzo di una singola parola mentre “'''#'''” rappresenta zero o più parole.

I messaggi del modello Topic inviati a un Exchange non possono avere una Routing key arbitraria, ma deve essere un elenco di parole, delimitato da punti. Esempi validi di chiavi di Routing key sono "''stock.usd.nyse''", "''nyse.vmw''", "''quick.orange.rabbit''".

Le code possono essere collegate con l’Exchange usando modelli come  "''* .usd. *''", ottenendo tutti i messaggi in cui "''usd''" è una parte centrale del messaggio.

[[File:Topic_model.png|miniatura|260x260px330x330px|Esempio di comportamento nel modello Topic]]

Facendo riferimento all'immagine che riporta un esempio di comportamento del modello Topic, tre differenti code vengono identificate dalla loro ''Binding key.'' Se il messaggio che arriva all’Exchange presenta una Routing key come “''shape''”, esso verrà inviato alla terza coda che rispetta esattamente il matching e alla seconda coda poiché nel proprio pattern è presente sia shape che il carattere "#", ovvero zero o più parole. Al contrario la prima coda non rispetta il matching poiché la struttura della sua chiave di legame richiede la presenza di due parole (di cui una deve essere ''shape'').

Line 89 ⟶ 82:

Per ottenere il comportamento di un Exchange Fanout dobbiamo utilizzare come Binding Key il semplice "#", che permette l’instradamento a prescindere dalla Routing Key poiché vi è sempre il matching con zero o più parole.

== RabbitMQ nei Data Center<ref>{{Cita web|url=http://fullstackmastery.com/2018/03/12/free-course-improve-design-architecture-rabbitmq/|titolo=fullstackmastery|accesso=25 maggio 2018|urlarchivio=https://web.archive.org/web/20180525204743/http://fullstackmastery.com/2018/03/12/free-course-improve-design-architecture-rabbitmq/|dataarchivio=25 maggio 2018|urlmorto=sì}}</ref> ==

Un cluster RabbitMQ è un [[Computer cluster|cluster]]<ref>{{Cita pubblicazione|autore=Maciej Rostanski ; Krzysztof Grochla ; Aleksander Seman|titolo=Evaluation of highly available and fault-tolerant middleware clustered architectures using RabbitMQ|rivista=|volume=|numero=}}</ref> conin piùcui nodiè Rabbitrichiesta ela vi è bisognopresenza di almeno due dinodi essiRabbit (preferibilmente 3). Uno deidi nodiessi è il nodo primario e gli altri sono chiamatidefiniti secondari. Il cluster RabbitMQ viene utilizzato poichèpoiché fornisce '''high availability ([[High Availability|HA]])''':, ovvero se un nodo si guasta, gli altri possono continuare a svolgere il loroproprio lavorocompito. Tutti i nodi devono trovarsi nella stessa [[Local Area Network|LAN]], poiché ogni nodo utilizzaverifica glila presenza degli altri attraverso il controllo degli ''[[:en:Heartbeat_(computinginformatica)|heartbeat]]''. perNel verificaremomento loin statocui degli altrii nodi., Quindiappartenenti se abbiamo un problema traa due [[Centro elaborazione dati|Data Center]] i nodi, registrano launa disconnessione, efanno funzionerannofronte a tale problematica continuando nel funzionamento in modo indipendente; (tuttaviatale scenario non èoffre questopiù loi scenariovantaggi ideale)di affidabilità presenti prima della disconnessione.

Nel cluster RabbitMQ, gli scambi e le configurazioni vengono replicati su tutti i nodi al fine di ottenere HA. Quindi ogniOgni nodo può essere dichiarato come nodo Disk-backed o nodo Memory-backed. Vi è inoltre bisogno di almeno un nodo Disk-backed per far sì che sepossa, l’interonell'eventualità sistema dovesse averedi un crash, talesull’intero nodo possasistema, mantenere le informazioni e garantire dunque maggiore affidabilità. I nodi Memory-backed sono molto più veloci nella replica dei dati.

Per ottenere un cluster HA, è necessario disporre di '''Mirrored Queues'''<ref>{{Cita web|url=https://hpuwalbvt.updog.co/aHB1d2FsYnZ0MTkzNTE4Mjk3OA.pdf|titolo=RabbitMQ in Action: Distributed Messaging for Everyone|accesso=25 maggio 2018|urlarchivio=https://web.archive.org/web/20180526041241/https://hpuwalbvt.updog.co/aHB1d2FsYnZ0MTkzNTE4Mjk3OA.pdf|dataarchivio=26 maggio 2018|urlmorto=sì}}</ref>., Leche offrono un miglioramento rispetto alle prestazioni delle Regular QueusQueues'''.''' Queste ultime risiedono sul nodo che hanno dichiarato o creato. Le Regular Queuse hanno una miglior performance in velocità di esecuzione/message throughput, ma sono ''time sensitive'' e ''time limited''. Al contrario, lale Mirrored QueueQueues fapermettono sìla cheduplicazione idei messaggi vengano duplicati su tutti i nodi, eal presentinocosto di una peggiore performance/message throughput,. poichéNe talederiva tipologia di coda deve replicare un messaggio su tutti i nodi. Quindi,che il throughput dell’intero sistema dipende dai throughput di tutti i nodi nel sistema. La soluzione migliore è un '''[[trade-off]]''' tra i due scenari analizzati precedentemente, poiché risulta essere più affidabile garantendo una copia del messaggio su tutti i nodi.

La soluzione migliore è rappresentata dal [[trade-off]] dei due scenari analizzati precedentemente, garantendo una copia del messaggio su tutti i nodi e dunque maggiore affidabilità.

=== Esempio<ref>{{Cita web|url=https://insidethecpu.com/2014/11/17/load-balancing-a-rabbitmq-cluster/|titolo=Load Balancing a RabbitMQ Cluster}}</ref> ===

In un cluster RabbitMQ HA con bilanciamento del carico, in cui le code rappresentano strutture singolari, ovvero che non esistono su più di un nodo, si ha lo scenario di seguito descritto. I nodi 1 e 3 vengono replicati, in modo tale che le istantanee di tutte le code compatibili con HA siano sincronizzate su ciascun nodo. Viene creata una nuova coda che, essendo il [[Load balancing|Load Balancer]] schedulato in modalità [[Schedulazione Roundround Robinrobin|Round-Robinround robin]], risiede sul nodo 2 ed è definita “NewQueue” (tuttavia è possibile scegliere esplicitamente il nodo su cui si desidera che risiedacreare la coda).

La politica HA richiede di replicare la coda su tutti i nodi presenti nel cluster. Nel momento in cui vengono aggiunti messaggi alla coda, essi vengono replicati su ciascun nodo. In sostanza, viene eseguita un'istantanea della coda replicata su ciascun nodo attraverso un'attività in background asincrona, ogni qual volta lo stato della coda cambia. Quindi, collegandosi a RabbitMQ e puntando a "NewQueue", Load Balancer indirizza ad un nodo appropriato. Si può assumere di essere connessi all'istanza di "NewQueue" che risiede su quel nodo.

Tuttavia non è questo il caso. Infatti si deve sempre tenere a mente che una coda RabbitMQ è una struttura singolare, cioè esiste solo sul nodo su cui è stata creata, indipendentemente dal criterio HA. Una coda sarà sempre master ed avrà associati da ''0 ,1,... ,N'' slave. In base all'esempio precedente, "NewQueue" del nodo 2 è la coda master, poiché questo è il nodo su cui è stata creata, mentre i nodi 1 e 3 rappresentano gli slave.

Supponendo che il nodo 2 “muoia”, tecnicamente esso non restituisce un ''heartbeat'' ed è considerato disaggregato. In tale scenario la coda master "NewQueue" non è più disponibile, quindi RabbitMQ promuove l'istanza dello slave "NewQueue" sul nodo 1 o 3. Questo è un comportamento HAevidenzia standardi invantaggi di RabbitMQ per quanto concerne gli aspetti dell'affidabilità.

TornandoNel allo scenario di default,caso in cui tutti e 3 i nodi sono vivi e l'istanza "NewQueue" sul Nodonodo 2 è master, nelsi torna allo scenario di default. Nel momento in cui RabbitMQ si collega, con targeting "NewQueue", il Load Balancer determina un nodo appropriato, attraverso lo scheduling Round-Robin, scegliendo ad esempio il nodo 3. RabbitMQ reindirizza al nodo 2 (master), portando a termine con successo una connessione all'istanza master di "NewQueue".

Nonostante il fatto che le code siano replicate su ciascun nodo, esiste una sola istanza disponibile di ogni coda e risiede sul nodo su cui è stata creata o, in caso di errore, sull'istanza che viene promossa come master. '''RabbitMQ opera al fine di indirizzarereindirizzare al nodo master in ogni caso.''' Questo significa effettuare un hop di rete extra per raggiungere la coda prevista. Nell’esempio con 3 nodi e un Load Balancer bilanciato in modo uniforme, si sostiene un ulteriore salto di rete su circa il 66% delle richieste. Solo una richiesta su tre viene indirizzata al nodo corretto.

Per garantire l’instradamento di ogni richiesta al nodo corretto, ci sono due possibilità:

Line 114 ⟶ 109:

# Distribuire le code in modo uniforme nei nodi.

Nel primo caso, l’applicazione client deve essere a conoscenza di tutti i nodi nel cluster RabbitMQ e deve anche sapere dove si trova ogni coda master.

La seconda soluzione offre un design in cui le code non sono collegate a nodi singoli. Tornando all’esempio, vengono istanziate 3 code;: "''NewQueue1''", "''NewQueue2''" e "''NewQueue3''", ognuna su un nodo separato. L’applicazione client può ora implementare una funzione randomizzante che seleziona una delle tre precedenti code e si connette esplicitamente ad essa.

==Esempi==

Line 122 ⟶ 117:

===Invio===

Il seguente codice stabilisce una connessione, controlla l'esistenza della coda, invia il messaggio e chiude la connessione:

<sourcesyntaxhighlight lang="python">

#!/usr/bin/env python

import pika

Line 133 ⟶ 128:

print(" [x] Sent 'Hello World!'")

connection.close()

</syntaxhighlight>

</source>

===Ricezione===

Il seguente codice stabilisce una connessione, controlla l'esistenza della coda, riceve il messaggio e lo stampa a schermo:

<sourcesyntaxhighlight lang="python">

#!/usr/bin/env python

import pika

Line 149 ⟶ 144:

channel.basic_consume(callback, queue='hello', no_ack=True)

channel.start_consuming()

</syntaxhighlight>

</source>

== Note ==

<references />

== Bibliografia ==

* https://www.3pillarglobal.com/insights/rabbitmq-understanding-message-broker {{Webarchive|url=https://web.archive.org/web/20161102173706/http://www.3pillarglobal.com/insights/rabbitmq-understanding-message-broker |date=2 novembre 2016 }}

* [https://www.packtpub.com/application-development/rabbitmq-essentials RabbitMQ Essentials] - David Dossot - April 2014 - Packt Publishing

* https://derickbailey.com/categories/rabbitmq/ {{Webarchive|url=https://web.archive.org/web/20160525013619/http://derickbailey.com/categories/rabbitmq/ |date=25 maggio 2016 }}

* https://web.archive.org/web/2013060205494020180515071756/http://www.rabbitmq.com/newsprotocols.html

* https://www.youtube.com/watch?v=XjuiZM7JzPw

* httphttps://www.rabbitmq.com/getstarted.html

* https://web.archive.org/web/20180525204743/http://fullstackmastery.com/2018/03/12/free-course-improve-design-architecture-rabbitmq/

* https://web.archive.org/web/20130602054940/http://www.rabbitmq.com/news.html

* https://compose.com/databases/rabbitmq {{Webarchive|url=https://web.archive.org/web/20180520124500/https://compose.com/databases/rabbitmq |date=20 maggio 2018 }}

== Voci correlate ==

*[[Apache ActiveMQ|ActiveMQ]]

*[[HornetQ]]

*[[Apache Qpid]]

*[[Advanced Message Queuing Protocol]]

*[[MQTT]]

*[[Streaming Text Oriented Messaging Protocol|STOMP]] (RabbitMQ supporta STOMP)<ref>{{Cita web|url=https://www.rabbitmq.com/docs/stomp|titolo=STOMP Plugin {{!}} RabbitMQ|sito=www.rabbitmq.com|lingua=en|accesso=2024-09-25}}</ref>

*[[STOMP]]

*[[Centro elaborazione dati|Data Center]]

== Altri progetti ==

{{Portale|informatica}}

{{interprogetto}}

== BibliografiaCollegamenti esterni ==

==* {{Collegamenti Esterni ==esterni}}

* Joern Barthel (2009-09-13). "[https://www.infoq.com/articles/AMQP-RabbitMQ Getting started with AMQP and RabbitMQ]" Joern Barthel (2009-09-13)

{{Portale|informatica}}

* https://www.3pillarglobal.com/insights/rabbitmq-understanding-message-broker

* [https://www.packtpub.com/application-development/rabbitmq-essentials RabbitMQ Essentials] - David Dossot - April 2014 - Packt Publishing

* https://derickbailey.com/categories/rabbitmq/

* https://www.rabbitmq.com/protocols.html

* https://www.youtube.com/watch?v=XjuiZM7JzPw

* http://www.rabbitmq.com/getstarted.html

* http://fullstackmastery.com/2018/03/12/free-course-improve-design-architecture-rabbitmq/

* https://web.archive.org/web/20130602054940/http://www.rabbitmq.com/news.html

* https://compose.com/databases/rabbitmq

== Approfondimenti ==

* Joern Barthel (2009-09-13). "[https://www.infoq.com/articles/AMQP-RabbitMQ Getting started with AMQP and RabbitMQ]"

== Collegamenti Esterni ==

<references />