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

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!

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/

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.