RabbitMQ: differenze tra le versioni

Versione delle 20:16, 21 nov 2020

Versione attuale delle 11:14, 22 mar 2025

(23 versioni intermedie di 11 utenti non mostrate)

Riga 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 '''[[:en:Open_Telecom_Platform|Open Telecom Platform]]'''<ref>{{Cita web|url=https://pdfs.semanticscholar.org/af89/dc63c4491b430a3de659e364ed28f5685840.pdf|titolo=Open telecom platform}}</ref> (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.

Line 33 ⟶ 31:

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 AMQP.

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.|310x310px]]

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 46 ⟶ 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 ===

Line 55 ⟶ 53:

=== Direct ===

[[File:Direct_model.png|miniatura|330x330px|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 è vincolato con la chiave di binding ''Orange'', Q2 con ''Yellow'' e Q3 con ''Orange'', ''Black'' e ''Green''.

Line 66 ⟶ 64:

==== 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 ===

Line 75 ⟶ 73:

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|330x330px|Esempio di comportamento nel modello Topic]]

Line 85 ⟶ 83:

== 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> in cui è richiesta la presenza di almeno due nodi Rabbit (preferibilmente 3). Uno di essi è il nodo primario e gli altri sono definiti secondari. Il cluster RabbitMQ viene utilizzato poiché fornisce '''high availability ([[High Availability|HA]]),''' ovvero se un nodo si guasta, gli altri possono continuare a svolgere il proprio compito. Tutti i nodi devono trovarsi nella stessa [[Local Area Network|LAN]], poiché ogni nodo verifica la presenza degli altri attraverso il controllo degli ''[[:en:Heartbeat_(computinginformatica)|heartbeat]]''. Nel momento in cui i nodi, appartenenti a due [[Centro elaborazione dati|Data Center]], registrano una disconnessione, fanno fronte a tale problematica continuando nel funzionamento in modo indipendente; tale scenario non offre più i vantaggi 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. Ogni nodo può essere dichiarato come nodo '''Disk-backed''' o nodo '''Memory-backed'''. Vi è bisogno di almeno un nodo Disk-backed che possa, nell'eventualità di un crash sull’intero sistema, 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>, che offrono un miglioramento rispetto alle prestazioneprestazioni delle '''Regular Queues'''.''' Queste ultime risiedono sul nodo dichiarato o creato e hanno una miglior performance in velocità di esecuzione/message throughput, ma sono ''time sensitive'' e ''time limited''. Al contrario, le Mirrored Queues permettono la duplicazione dei messaggi su tutti i nodi, al costo di una peggiore performance/message throughput. Ne deriva che il throughput dell’intero sistema dipende dai throughput di tutti i nodi nel sistema.

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 creare 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.

Line 104 ⟶ 102:

Nel caso in cui tutti e 3 i nodi sono vivi e l'istanza "NewQueue" sul nodo 2 è master, si 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 reindirizzare 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 152 ⟶ 150:

== 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/20180515071756/http://www.rabbitmq.com/protocols.html

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

Line 160 ⟶ 158:

* 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]]

== ApprofondimentiAltri progetti ==

{{interprogetto}}

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

== Collegamenti esterni ==

* {{Collegamenti 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}}