Las colas de Rabbit residen en la memoria y, por lo tanto, serán mucho más rápidas que implementar esto en una base de datos. Una (buena) cola de mensajes dedicada también debe proporcionar características esenciales relacionadas con la cola como el control de aceleración / flujo, y la capacidad de elegir diferentes algoritmos de enrutamiento, para nombrar una pareja (el conejo proporciona estos y más). Dependiendo del tamaño de su proyecto, es posible que también desee que el componente de paso de mensajes esté separado de su base de datos, de modo que si un componente experimenta una carga pesada, no necesariamente obstaculice la operación del otro.
En cuanto a los problemas que mencionaste:
encuestas manteniendo la base de datos dinámica y de bajo rendimiento : con Rabbitmq, los productores pueden enviar actualizaciones a los consumidores, lo que es mucho más eficaz que las encuestas. Los datos simplemente se envían al consumidor cuando es necesario, lo que elimina la necesidad de controles innecesarios.
bloqueo de la mesa -> nuevamente bajo rendimiento: no hay mesa para bloquear: P
millones de filas de tareas -> nuevamente el sondeo es de bajo rendimiento: como se mencionó anteriormente, Rabbitmq funcionará más rápido ya que reside en la RAM y proporciona control de flujo. Si es necesario, también puede usar el disco para almacenar mensajes temporalmente si se queda sin RAM. Después de 2.0, Rabbit ha mejorado significativamente su uso de RAM. Las opciones de agrupamiento también están disponibles.
En lo que respecta a AMQP, diría que una característica realmente genial es el "intercambio" y la capacidad para que se dirija a otros intercambios. Esto le brinda más flexibilidad y le permite crear una amplia gama de elaboradas tipologías de enrutamiento que pueden ser muy útiles al escalar. Para un buen ejemplo, vea:
(fuente: springsource.com )
y: http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/
Finalmente, en lo que respecta a redis, sí, se puede usar como intermediario de mensajes y puede funcionar bien. Sin embargo, Rabbitmq tiene más funciones de cola de mensajes que redis, ya que rabbitmq se creó desde cero para ser una cola de mensajes dedicada de nivel empresarial con todas las funciones. Redis, por otro lado, fue creado principalmente para ser un almacén de valores clave en memoria (aunque ahora hace mucho más que eso; incluso se lo conoce como una navaja suiza). Aún así, he leído / escuchado a muchas personas lograr buenos resultados con Redis para proyectos de menor tamaño, pero no he escuchado mucho sobre esto en aplicaciones más grandes.
Aquí hay un ejemplo de redis que se está utilizando en una implementación de chat de sondeo largo: http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/