RabbitMQ: differenze tra le versioni

Versione delle 13:18, 25 mag 2018

Versione delle 13:35, 25 mag 2018

Riga 59:

[[File:Direct_model.png|miniatura|270x270px|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 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.

Line 91 ⟶ 89:

== RabbitMQ nei Data Center<ref>{{Cita web|url=http://fullstackmastery.com/2018/03/12/free-course-improve-design-architecture-rabbitmq/|titolo=fullstackmastery}}</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> con più nodi Rabbit e abbiamo bisogno di almeno due di essi (preferebilmente 3). Uno dei nodi è il nodo primario e gli altri sono chiamati secondari. Il cluster RabbitMQ viene utilizzato perché fornisce '''high availability ([[High Availability|HA]])''': se un nodo si guasta, gli altri possono continuare a svolgere il loro lavoro. Tutti i nodi devono trovarsi nella stessa [[Local Area Network|LAN]], poiché ogni nodo utilizza gli ''[[:en:Heartbeat_(computing)|heartbeat]]'' per verificare lo stato degli altri nodi. Quindi se abbiamo un problema tra 2 [[Centro elaborazione dati|Data Center]] i nodi registrano la disconnessione e funzioneranno in modo indipendente (tuttavia non è questo lo scenario ideale).

Nel cluster RabbitMQ, gli scambi e le configurazioni vengono replicati su tutti i nodi al fine di ottenere HA. Quindi ogni nodo può essere dichiarato come nodo Disk-backed o nodo Memory-backed. Abbiamo bisogno di almeno un nodo Disk-backed per farsi che se l’intero sistema abbia un crash, tale nodo mantenga le informazioni. 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}}</ref>. Le Regular Queus risiedono sul nodo che hanno dichiarato o creato. Le Regular Queus hanno una miglior performance in velocità di esecuzione/message throughput, ma sono time sensitive e time limited. Al contrario, la Mirrored Queue fa sì che i messaggi vengano duplicati su tutti i nodi e presentino una peggiore performance/message throughput poiché deve replicare un messaggio su tutti i nodi. Quindi, il throughput dell’intero sistema dipende dai throughput di tutti i nodi nel sistema. La soluzione migliore risulta essere un '''[[trade-off]]''' tra i due scenari analizzati precedentemente, poiché il trade-off risulta essere più affidabile in quanto abbiamo una copia del messaggio su tutti i nodi.

=== 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 il seguente scenario. 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, essendo [[Load balancing|Load Balancer]] schedulato in modalità [[Schedulazione Round Robin|Round-Robin]], essa verrà creata sul nodo 2 e definita “NewQueue” (tuttavia è possibile scegliere esplicitamente il nodo su cui si desidera che risieda 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 ... 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, RabbitMQ promuove l'istanza dello slave "NewQueue" sul nodo 1 o 3. Questo è un comportamento HA standard in RabbitMQ.

Tornando allo scenario di default, tutti e 3 i nodi sono vivi, e l'istanza "NewQueue" sul Nodo 2 è master. Collegandosi RabbitMQ, 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 indirizzare 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 su tre richieste viene indirizzata al nodo corretto.

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

# Connettersi esplicitamente al nodo su cui si trova la coda di destinazione.

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