RabbitMQ: differenze tra le versioni

Versione delle 15:10, 28 giu 2024

Versione attuale delle 11:14, 22 mar 2025

(Una versione intermedia di un altro utente 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.

Un ''[[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 ==

Riga 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

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

Riga 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''.

Riga 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 ''[[Heartbeat_(informatica)|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 prestazioni 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.

Riga 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à:

Riga 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 }}

Riga 166:

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