¿Por qué necesitamos corredores de mensajes como RabbitMQ en una base de datos como PostgreSQL?


215

Soy nuevo en los corredores de mensajes como RabbitMQ que podemos usar para crear tareas / colas de mensajes para un sistema de programación como Celery .

Ahora, aquí está la pregunta:

  • Puedo crear una tabla en PostgreSQL que se puede agregar con nuevas tareas y consumir por el programa de consumo como Celery.

  • ¿Por qué demonios querría configurar una tecnología completamente nueva para esto como RabbitMQ?

Ahora, creo que el escalado no puede ser la respuesta ya que nuestra base de datos como PostgreSQL puede funcionar en un entorno distribuido.

Busqué en Google qué problemas plantea la base de datos para el problema en particular, y encontré:

  • el sondeo mantiene la base de datos ocupada y de bajo rendimiento
  • bloqueo de la mesa -> nuevamente bajo rendimiento
  • millones de filas de tareas -> nuevamente, el sondeo es de bajo rendimiento

Ahora, ¿cómo RabbitMQ o cualquier otro agente de mensajes como ese resuelve estos problemas?

Además, descubrí que el AMQPprotocolo es lo que sigue. ¿Qué hay de bueno en eso?

¿Se puede usar Redis también como agente de mensajes? Me parece más análogo a Memcached que RabbitMQ.

¡Por favor, arroja algo de luz sobre esto!


99
El impacto del bloqueo debería ser mucho menor con PostgreSQL porque implementa MVCC donde los lectores no están bloqueados por los escritores y viceversa. La mayoría de los artículos que he encontrado criticando el uso de bases de datos como colas de mensajes tienen MySQL en mente.
CadentOrange

Un agente de mensajes mueve datos entre nodos, mientras que una base de datos mantiene los datos en un solo lugar. El hecho de que pueda acceder a los datos en una base de datos desde múltiples nodos, por lo visto, no lo convierte en una buena herramienta para transferir datos rápidamente entre nodos.
theMayer

2
"sistema de programación como celery" - Acabo de aprender algo que será útil en mi diseño, a partir de la pregunta . Ahora para leer las respuestas ...
Mark K Cowan

el uso del agente de mensajes productor y consumidor está desacoplado.
giorgi dvalishvili

Puede ver el siguiente enlace. Tiene una amplia descripción: stackoverflow.com/a/51377756/3073945
Md. Sajedul Karim

Respuestas:


110

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/


2
He implementado una implementación JMS (es decir, un sistema de paso de mensajes) sobre una base de datos. Puedo decirte que es posible, pero no es divertido y generalmente no vale la pena hacerlo. Algunos de los problemas que menciona pueden solucionarse, pero aumentan bastante la complejidad. En general, estoy de acuerdo: use un sistema MQ dedicado, si lo necesita. Sin embargo, para cargas de trabajo bajas, puede salirse con la suya en la base de datos.
Joachim Sauer

1
Simplemente cubriste todas las preocupaciones / dudas. Respuesta impresionante!
Yugal Jindle

Eso es interesante. ¿Qué pasa con la consistencia por cierto? ¿Qué pasa si hay cientos de trabajos en una cola y el nodo que los retiene se bloquea?
Mahn

22
En realidad, con PostgreSQL no hay sondeo (vea NOTIFY) ni hay bloqueos de tabla (vea MVCC). Aunque PostgreSQL todavía no está diseñado para la cola de mensajes, no es completamente inadecuado.
jkj

3
Al igual que lo que dijo @jkj, hay NOTIFICACIÓN y no hay bloqueos de tablas. El único problema parece ser el alto ancho de banda de los mensajes. ¿No podría tener una instancia de PostgreSQL dedicada en lugar de mantener un sistema completamente nuevo como Rabbit? Puede 1) usar una sola instancia de PostgreSQL hasta llegar a un cuello de botella, luego 2) usar un Postgres dedicado, y finalmente 3) cambiar fácilmente a Rabbit como su corredor. Parece que comenzar con Rabbit es una optimización previa.
Joe

72

PostgreSQL 9.5

PostgreSQL 9.5 incorpora SELECT ... FOR UPDATE ... SKIP LOCKED. Esto hace que la implementación de sistemas de colas de trabajo sea mucho más simple y fácil. Es posible que ya no necesite un sistema de colas externo, ya que ahora es fácil recuperar 'n' filas que ninguna otra sesión ha bloqueado, y mantenerlas bloqueadas hasta que confirme que el trabajo está hecho. Incluso funciona con transacciones de dos fases para cuando se requiere coordinación externa.

Los sistemas de colas externas siguen siendo útiles, ya que proporcionan funcionalidad enlatada, rendimiento comprobado, integración con otros sistemas, opciones de escala horizontal y federación, etc. Sin embargo, para casos simples ya no los necesita realmente.

versiones mas antiguas

No necesita tales herramientas, pero usar una puede facilitarle la vida. Hacer colas en la base de datos parece fácil, pero descubrirá en la práctica que las colas concurrentes confiables y de alto rendimiento son realmente difíciles de hacer correctamente en una base de datos relacional.

Por eso existen herramientas como PGQ .

Puede deshacerse del sondeo en PostgreSQL utilizando LISTENy NOTIFY, pero eso no resolverá el problema de distribuir de manera confiable las entradas de la parte superior de la cola a exactamente un consumidor al tiempo que conserva la operación altamente concurrente y no bloquea las inserciones. Todas las soluciones simples y obvias que cree que resolverán ese problema en realidad no lo hacen en el mundo real, y tienden a degenerar en versiones menos eficientes de la búsqueda de colas de un solo trabajador.

Si no necesita búsquedas de colas de múltiples trabajadores altamente concurrentes, entonces usar una sola tabla de colas en PostgreSQL es completamente razonable.


11
la línea lo reliably handing out entries off the top of the queue to exactly one consumer while preserving highly concurrent operation and not blocking inserts. resume, ¿verdad?
Yugal Jindle
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.