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/