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 funciones esenciales relacionadas con la cola, como la limitación/control de flujo, y la capacidad de elegir diferentes algoritmos de enrutamiento, por nombrar un par (el conejo proporciona estos y más). Según el tamaño de su proyecto, también puede querer que el componente de paso de mensajes esté separado de su base de datos, de modo que si un componente experimenta una gran carga, no tiene por qué obstaculizar el funcionamiento del otro.
En cuanto a los problemas que mencionaste:
-
sondeo que mantiene la base de datos ocupada y de bajo rendimiento :Usando Rabbitmq, los productores pueden empujar actualizaciones a los consumidores, que es mucho más eficaz que el sondeo. Los datos simplemente se envían al consumidor cuando es necesario, eliminando la necesidad de cheques inútiles.
-
bloqueo de la tabla -> de nuevo bajo rendimiento: No hay mesa para bloquear :P
-
millones de filas de tareas -> de nuevo el sondeo tiene un rendimiento bajo: Como se mencionó anteriormente, Rabbitmq funcionará más rápido ya que reside en 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 mejoró significativamente en su uso de RAM. Las opciones de agrupación también están disponibles.
Con respecto a AMQP, diría que una característica realmente interesante es el "intercambio" y la capacidad de enrutar a otros intercambios. Esto le brinda más flexibilidad y le permite crear una amplia gama de tipologías de enrutamiento elaboradas que pueden ser muy útiles al escalar. Para ver un buen ejemplo, consulte:
(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, se creó 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 oído hablar mucho de él en aplicaciones más grandes.
Este es un ejemplo del uso de Redis en una implementación de chat de sondeo prolongado:http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/
