Perché abbiamo bisogno di broker di messaggi come RabbitMQ su un database come PostgreSQL?


215

Sono nuovo ai broker di messaggi come RabbitMQ che possiamo usare per creare attività / code di messaggi per un sistema di pianificazione come Celery .

Ora, ecco la domanda:

  • Posso creare una tabella in PostgreSQL che può essere aggiunta con nuove attività e utilizzata dal programma consumer come Celery.

  • Perché mai dovrei impostare una tecnologia completamente nuova per questo come RabbitMQ?

Ora, credo che il ridimensionamento non possa essere la risposta poiché il nostro database come PostgreSQL può funzionare in un ambiente distribuito.

Ho cercato su Google per quali problemi pone il database per il problema specifico e ho trovato:

  • il polling mantiene il database occupato e poco performante
  • blocco del tavolo -> di nuovo a basse prestazioni
  • milioni di file di attività -> di nuovo, il polling ha prestazioni scarse

Ora, come fa RabbitMQ o qualsiasi altro broker di messaggi del genere a risolvere questi problemi?

Inoltre, ho scoperto che il AMQPprotocollo è ciò che segue. Cosa c'è di bello in questo?

Redis può essere utilizzato anche come broker di messaggi? Lo trovo più analogo a Memcached di RabbitMQ.

Per favore, fai luce su questo!


9
L'impatto del blocco dovrebbe essere molto inferiore con PostgreSQL perché implementa MVCC in cui i lettori non sono bloccati dagli scrittori e viceversa. La maggior parte degli articoli che ho trovato criticare l'uso dei database in quanto le code dei messaggi hanno in mente MySQL.
CadentOrange

Un broker di messaggi sposta i dati tra i nodi, mentre un database conserva i dati in un unico posto. Il fatto che sia possibile accedere ai dati in un database da più nodi non lo rende un buon strumento per trasferire rapidamente i dati tra nodi.
theMayer,

2
"sistema di programmazione simile celery" - Ho appena imparato qualcosa che sarà utile nella mia progettazione, dalla domanda . Ora per leggere le risposte ...
Mark K Cowan,

l'utilizzo del produttore e del consumatore di broker di messaggi è disaccoppiato.
giorgi dvalishvili,

È possibile visualizzare il seguente link. Ha una vasta descrizione: stackoverflow.com/a/51377756/3073945
. Md Sajedul Karim

Risposte:


110

Le code di Rabbit risiedono in memoria e saranno quindi molto più veloci dell'implementazione in un database. Una (buona) coda di messaggi dedicata dovrebbe anche fornire funzionalità relative all'accodamento essenziali come il controllo di limitazione / flusso e la possibilità di scegliere diversi algoritmi di routing, per nominare una coppia (coniglio fornisce questi e altro). A seconda delle dimensioni del progetto, è possibile che si desideri che il componente che passa il messaggio sia separato dal database, in modo che se un componente presenta un carico pesante, non è necessario che ostacoli l'operazione dell'altro.

Per quanto riguarda i problemi che hai citato:

  • polling mantenendo la buzy database e basso performante : Utilizzando RabbitMQ, i produttori possono spingere gli aggiornamenti per i consumatori che è molto più performante rispetto polling. I dati vengono semplicemente inviati al consumatore quando è necessario, eliminando la necessità di controlli inutili.

  • blocco della tabella -> di nuovo a basso rendimento: non esiste una tabella da bloccare: P

  • milioni di righe di attività -> di nuovo il polling ha prestazioni scarse: come accennato in precedenza, Rabbitmq funzionerà più velocemente poiché risiede nella RAM e fornisce il controllo del flusso. Se necessario, può anche utilizzare il disco per archiviare temporaneamente i messaggi se si esaurisce la RAM. Dopo 2.0, Rabbit è notevolmente migliorato nell'utilizzo della RAM. Sono inoltre disponibili opzioni di clustering.

Per quanto riguarda AMQP, direi che una caratteristica davvero interessante è lo "scambio" e la capacità di indirizzarlo verso altri scambi. Ciò offre maggiore flessibilità e consente di creare una vasta gamma di tipologie di routing elaborate che possono rivelarsi molto utili durante il ridimensionamento. Per un buon esempio, vedi:


(fonte: springsource.com )

e: http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

Infine, per quanto riguarda il redis, sì, può essere usato come broker di messaggi e può fare bene. Tuttavia, Rabbitmq ha più funzioni di accodamento dei messaggi rispetto a redis, poiché rabbitmq è stato creato da zero per essere una coda di messaggi dedicata a livello aziendale con funzionalità complete. D'altra parte, Redis è stato creato principalmente per essere un negozio di valori-chiave in memoria (anche se ora fa molto di più di questo; viene persino definito un coltellino svizzero). Tuttavia, ho letto / sentito molte persone che ottengono buoni risultati con Redis per progetti di dimensioni più ridotte, ma non ne ho sentito parlare molto in applicazioni più grandi.

Ecco un esempio di redis utilizzato in un'implementazione di chat a lungo polling: http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/


2
Ho implementato un'implementazione JMS (ovvero un sistema di trasmissione di messaggi) in cima a un database. Posso dirti che è possibile, ma non è divertente e di solito non paga per farlo. Alcuni dei problemi citati possono essere risolti, ma aumentano notevolmente la complessità. Tutto sommato concordo: utilizzare un sistema MQ dedicato, se necessario. Per carichi di lavoro bassi, tuttavia, è possibile cavarsela nel DB.
Joachim Sauer,

1
Hai semplicemente coperto tutte le preoccupazioni / dubbi. Risposta fantastica!
Yugal Jindle,

Interessante. E la coerenza tra l'altro? Cosa succede se ci sono centinaia di lavori su una coda e il nodo che li tiene in crash di ram?
Mahn,

22
In realtà, con PostgreSQL non c'è polling (vedi NOTIFY) né ci sono blocchi di tabella (vedi MVCC). Sebbene PostgreSQL non sia ancora progettato per l'accodamento dei messaggi, non è del tutto inadatto.
jkj,

3
Come quello che ha detto @jkj, c'è NOTIFY e nessun blocco delle tabelle. L'unico problema sembra l'elevata larghezza di banda dei messaggi. Non potresti avere un'istanza PostgreSQL dedicata invece di mantenere un sistema completamente nuovo come Rabbit? Puoi 1) utilizzare una singola istanza PostgreSQL fino a raggiungere un collo di bottiglia, quindi 2) utilizzare un Postgres dedicato, quindi infine 3) passare facilmente a Rabbit come broker. Sembra che iniziare con Rabbit sia pre-ottimizzato.
Joe,

72

PostgreSQL 9.5

PostgreSQL 9.5 incorpora SELECT ... FOR UPDATE ... SKIP LOCKED. Ciò rende l'implementazione di sistemi di accodamento funzionanti molto più semplici e facili. Potrebbe non essere più necessario un sistema di accodamento esterno poiché è ora semplice recuperare 'n' righe che nessun'altra sessione ha bloccato e tenerle bloccate fino a quando non si conferma la conclusione del lavoro. Funziona anche con transazioni in due fasi per il coordinamento esterno.

I sistemi di accodamento esterni rimangono utili, fornendo funzionalità predefinite, prestazioni comprovate, integrazione con altri sistemi, opzioni per il ridimensionamento orizzontale e la federazione, ecc. Tuttavia, per casi semplici non ne hai più bisogno.

Versioni precedenti

Non hai bisogno di tali strumenti, ma usarne uno potrebbe semplificarti la vita. Fare la fila nel database sembra facile, ma scoprirai in pratica che la messa in coda simultanea ad alte prestazioni e affidabile è davvero difficile da fare in un database relazionale.

Ecco perché esistono strumenti come PGQ .

Puoi eliminare il polling in PostgreSQL usando LISTENe NOTIFY, ma ciò non risolverà il problema di distribuire in modo affidabile le voci dalla parte superiore della coda a un solo consumatore preservando operazioni altamente simultanee e non bloccando gli inserti. Tutte le soluzioni semplici e ovvie che pensi risolveranno quel problema in realtà non lo fanno nel mondo reale e tendono a degenerare in versioni meno efficienti del recupero della coda per singolo lavoratore.

Se non hai bisogno di recuperi di coda multi-lavoratore altamente simultanei, usare una singola tabella di code in PostgreSQL è del tutto ragionevole.


11
la linea lo reliably handing out entries off the top of the queue to exactly one consumer while preserving highly concurrent operation and not blocking inserts. riassume - giusto?
Yugal Jindle,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.