Le code di Rabbit risiedono in memoria e saranno quindi molto più veloci rispetto all'implementazione in un database. Una (buona) coda di messaggi dedicata dovrebbe anche fornire funzionalità essenziali relative all'accodamento come limitazione/controllo del flusso e la possibilità di scegliere diversi algoritmi di instradamento, per nominarne un paio (coniglio fornisce questi e altro). A seconda delle dimensioni del tuo progetto, potresti anche volere che il componente di passaggio dei messaggi sia separato dal tuo database, in modo che se un componente subisce un carico pesante, non debba ostacolare il funzionamento dell'altro.
Per quanto riguarda i problemi che hai citato:
-
polling che mantiene il database occupato e con scarse prestazioni :Utilizzando Rabbitmq, i produttori possono spingere aggiornamenti per i consumatori che è molto più performante del polling. I dati vengono semplicemente inviati al consumatore quando è necessario, eliminando la necessità di inutili controlli.
-
blocco del tavolo -> ancora una volta a basso rendimento: Non c'è una tabella da bloccare :P
-
milioni di righe di attività -> ancora una volta 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 la RAM esaurisce. Dopo la 2.0, Rabbit ha notevolmente migliorato l'utilizzo della RAM. Sono disponibili anche opzioni di clustering.
Per quanto riguarda AMQP, direi che una caratteristica davvero interessante è lo "scambio" e la possibilità di instradarlo ad altri scambi. Ciò offre maggiore flessibilità e consente di creare un'ampia gamma di elaborate tipologie di instradamento che possono tornare molto utili durante il ridimensionamento. Per un buon esempio, vedere:
(fonte:springsource.com)
e:http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/
Infine, per quanto riguarda Redis, sì, può essere utilizzato come broker di messaggi e può fare bene. Tuttavia, Rabbitmq ha più funzioni di accodamento messaggi rispetto a Redis, poiché rabbitmq è stato creato da zero per essere una coda di messaggi dedicata a livello aziendale con funzionalità complete. Redis, d'altra parte, è stato creato principalmente per essere un negozio di valori chiave in memoria (sebbene ora faccia molto di più; è anche indicato come un coltellino svizzero). Tuttavia, ho letto/sentito molte persone ottenere buoni risultati con Redis per progetti di piccole dimensioni, ma non ne ho sentito parlare molto in applicazioni più grandi.
Ecco un esempio di utilizzo di Redis in un'implementazione di chat con polling lungo:http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/
