RabbitMQ bilanciamento del carico del client

Question

Sto pilotando il coniglio mq e lo trovo abbastanza buono. Osservando la pagina di HA, trovo che la replica di scambio/coda funzioni bene.

Mi preoccupa il fatto che devo usare una TCP Loadbalancer per bilanciare il carico tra i nodi. È corretto?

Mi piacerebbe avere 2 nodi di un cluster con una politica di "replicare-all".

vorrei e l'editore o il consumatore sia in grado di connettersi a tutti i nodi in un round-robin simile comportamento. Sfortunatamente l'API client consente solo l'impostazione di un host per connessione.

C'è qualche (3a parte forse?) Alla connessione piscina come soluzione in modo un editore pubblica e di consumatori consuma da tutti i nodi?

Answer 1

non ho visto alcun client che il pool di connessioni per AMQP/RabbitMQ. AMQP gestisce più editori/consumatori in un singolo processo con i canali e alcuni client lo rendono facile da usare ma non sembrano gestire il failover automatico dei nodi utilizzando un pool di connessioni.

In un cluster non c'è bisogno di connettersi a tutti i nodi del cluster, consumare e pubblicano le operazioni saranno instradati correttamente all'interno del cluster. Per il consumo cercare di gestire processi singoli o multipli con più abbonamenti (almeno un consumo per ciascuna connessione) non è mai stata la massima priorità per me. Con il consumo di più processi, ciascuno collegato casualmente a RabbitMQ, sarà possibile mantenere la disponibilità qualora uno dei nodi RabbitMQ non riesca.

Gli editori in connessioni di lunga durata sono facilmente in grado di riconnettersi se viene rilevato un errore che causa meno di un secondo di interruzione, abbastanza piccolo in tutto ciò su cui ho lavorato per non essere un problema.

Da alcuni anni di utilizzo direi che la riconnessione a un nuovo host è il problema più semplice durante un failover con il difficile problema di gestione dello stato all'interno dell'applicazione in relazione alle connessioni AMQP esistenti. In pratica ho appena tenuto un elenco degli host disponibili e scelgo quello successivo per ogni nuova connessione. Ogni volta che la connessione si chiude, scegli un nuovo host e riprova. Significa un breve periodo in cui non puoi pubblicare e potrebbe essere più difficile se devi costantemente creare nuove connessioni in PHP.

A causa di flow control I bilanciatori di carico TCP possono essere più problemi quindi valgono. La contropressione TCP potrebbe non farcela attraverso il LB, facendo sì che gli editori pubblichino più velocemente di quanto riesca a gestire RabbitMQ. Nei test non scientifici ho avuto più problemi con la stabilità di RabbitMQ quando si trovava dietro un sistema di bilanciamento del carico quando i client si connettevano direttamente.

Answer 2

Non hai menzionato che tipo di client stai usando, ma per Python c'è l'eccellente libreria di Kombu. Kombu supporta sia connection and producer pools.

È inoltre possibile specificare diversi server AMQP con una strategia di failover round-robbin, shuffle o personalizzata when settting up a connection.

Answer 3

Per python nameko il modo suggerito per il raggiungimento dell'HA (Rabbitmq) è indicato here. Nameko riesce a raggiungere questo obiettivo, come il supporto libreria (kombu) supporta round-robin failover

AMQP_URI: pyamqp://guest:guest@rabbitmq1:5672/;pyamqp://guest:guest@rabbitmq2:5672/