RabbitMQ: differenze tra le versioni

Versione delle 11:55, 21 apr 2018

Versione delle 11:53, 23 mag 2018

Riga 19:

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>

Rabbit Technologies è nata nel 2007 come una joint venture tra LShift e CohesiveFT, ed è stata acquisita nell'aprile 2010 da SpringSource, una divisione di [[VMware Inc.|VMware]]. Il progetto è diventato parte del Pivotal Software a maggio 2013.

Nel Febbraio 2007 con queste parole la [[joint venture]] tra [https://tech.labs.oliverwyman.com/ LShift] e CohesiveFT lanciò sul mercato il software RabbitMQ, per divenire in poco tempo tra i più popolari strumenti di messaggistica asincrona.

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 architettonico per la convalida, la trasformazione e il routing dei messaggi. Il broker media la comunicazione tra le applicazioni, riducendo al minimo la consapevolezza reciproca che le applicazioni dovrebbero avere l'una per l'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'''. Attraverso questa modifica avviene l’implementazione del protocollo AMPQ.

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:Architettura_di_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.]]

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

* Direct

* Topic

Ognuna di queste categorie definisce un diverso comportamento di 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 ===

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.

[[File:Fanout.png|sinistra|miniatura|254x254px|Comportamento dell'Exchange nel modello Fanout]]

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

[[File:Modello_Direct.png|sinistra|miniatura|Comportamento dell'Exchange nel modello Direct]]

Nell'esempio, Q1 e Q2 sono vincolati con la chiave di binding ''Orange'', Q3 con ''Yellow'' e Q4 con ''Orange'', ''Black'' e ''Green''.

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

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

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

==== Fanout VS Direct ====

Nel Fanout i messaggi vengono inviati a tutte le code che sono legate all'Exchange senza verificare le chiave 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 due modelli visti in precedenza.  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.

==Esempi==

In questa sezione si trova un esempio di programma scritto in [[Python]] per inviare e ricevere messaggi su una coda.