Cola de mensajes. Base de datos vs MQ dedicado

17

Estoy siguiendo consejos sobre la cola de mensajes. Tenemos requisitos para que los "trabajos" se publiquen en una cola de mensajes.

La sugerencia original era simplemente usar una instancia de SQL Server y procesar mensajes a partir de eso. Todo lo que he leído en Internet sugiere que usar una base de datos para Message Queue no es una solución escalable. Por esta razón, se sugirió la idea de usar RabbitMQ o algún otro MQ de terceros.

La otra cosa a tener en cuenta es que el requisito para el "procesamiento del trabajo" no será inferior a 30 segundos, por lo que el proceso que realiza el trabajo sondeará la base de datos cada 30 segundos. Para mí, esto no parece tan malo y probablemente funcionaría bien sin agregar una gran carga a la base de datos.

Ya tenemos una base de datos en nuestros clientes que podríamos usar para esto, por lo que no agregará mucho soporte adicional requerido a nuestros clientes, mientras que si agregamos un MQ de terceros, habría soporte adicional para la configuración de la red, etc. considerable dado que hay muchos usuarios.

La otra opción que estaba considerando era permitir a los usuarios elegir entre cualquiera. Si son usuarios pequeños, entonces la solución SQL Server estará bien, pero si son usuarios más grandes, entonces les permitiremos configurar una solución MQ de terceros.

No estoy convencido de ninguna solución, me pregunto si alguien tiene algo que debería considerar o aconsejar.

user1653400
fuente
1
¿Son estos 'trabajos' un 'disparar y olvidar' o el proceso tendrá que volver a llamar por teléfono a casa para que el servidor sepa el estado de ese trabajo?
c_maker
¿Qué tan escalable debe ser? ¿Está ejecutando unos cientos de miles de mensajes por día o varios miles de millones?
Blrfl
Gracias por los comentarios: hay un requisito para que el trabajo se marque como incompleto (se consideran completos a menos que se marque como incompleto / fallido). Creo que no más de 20 000 mensajes al día. Lo más probable es que solo unos pocos miles.
user1653400
Use la herramienta más adecuada para el trabajo. Si necesita una cola de mensajes, use una cola de mensajes, no una base de datos. He visto personas que usan tablas de bases de datos como colas de mensajes antes y lo considero un antipatrón. Puede usar un destornillador como martillo, pero un martillo funciona mejor si necesita clavar un clavo. La mayoría de las veces cuando las personas hacen esto, es porque entienden las bases de datos pero no las colas de mensajes.
Jesper
Aquí hay algunos buenos consejos: rusanu.com/2010/03/26/using-tables-as-queues
Michael Green

Respuestas:

18

Todo lo que he leído en Internet sugiere que usar una base de datos para Message Queue no es una solución escalable.

La realidad frecuentemente ignorada por la multitud " no use X porque no escala " (el enlace contiene lenguaje que algunos pueden encontrar objetable) es que la escala no siempre es importante. Llegaría al extremo de decir que si se observan todas las aplicaciones en la faz del planeta en conjunto, la escala rara vez es importante.

Su comentario cita una tasa de 20,000 mensajes diarios, lo que significa que necesitaría soportar una tasa promedio de 0.23 mensajes por segundo (uno cada 4.3 segundos). Si su proyecto resulta ser dos órdenes de magnitud más exitoso de lo que esperaba, sus requisitos saltan al procesamiento de 23 mensajes por segundo, lo cual sería una tarea muy cómoda para mi teléfono móvil de cuatro años o una Frambuesa. Pi. Esto todavía no es una aplicación a gran escala, incluso si agrega otro par de órdenes de magnitud además de eso.

He visto (afortunadamente, desde el margen) que los proyectos terminan mal porque pasaron demasiado tiempo demasiado temprano obsesionándose con la escala que no iba a suceder o no tuvieron tiempo en absoluto y fueron aplastados por la escala que finalmente lo hizo. Como todo lo demás, hay un medio feliz. Si cree que la ampliación a gran escala para su aplicación es una posibilidad realista, no debería ser difícil hacer un caso de negocios para hacer la pequeña cantidad de trabajo adicional para generar suficiente abstracción en torno a partes no escalables que son económicas de implementar ahora . Hacer esto significa que más adelante , si surge una necesidad de escala, usted tiene una forma (y posiblemente los ingresos) de hacer un reemplazo total de esas partes sin tener que repensar todo el sistema.

Si bien el volumen de mensajes de su aplicación no va a hacer que una base de datos o un sistema de colas de mensajes suden incluso en hardware modesto, probablemente tenga otros requisitos sobre cómo se manejan sus transacciones de mensajes que hacen que una u otra sea una mejor opción. Esos requisitos son lo que debe evaluar.

Blrfl
fuente
Tengo una base de datos con millones de transacciones realizadas diariamente. que necesito procesar a través de sms. Actualmente estoy usando la tabla sql como cola, pero me atoro cuando recolecto una gran cantidad de datos. No puedo usar MQ porque necesito enrutar mis sms en función de la configuración en tiempo real. Si uso MQ, entonces no usa la configuración actual para el cliente. ya que estamos cambiando de proveedor en el back-end cuando algún proveedor no puede procesar. Entonces, ¿qué me sugieres en mi escenario?
mayur Rathod
@mayurRathod Ese tema parece forraje para una pregunta separada. Redacte con cuidado, porque una solicitud de herramientas o recursos específicos se cerrará como fuera de tema.
Blrfl
9

Las colas de mensajes realmente cobran importancia cuando tienes muchas de ellas y enrutan mensajes entre ellas, despliegan a más de un consumidor, etc.

Si solo tiene una única 'cola de trabajos' de cosas que desea procesar 'fuera de línea', entonces una tabla SQL funcionará bien.

No olvide asegurarse de tener alguna forma de marcar los trabajos en progreso, limpiar los viejos y alertar cuando el sistema se detiene. Pero para una sola cola, la gestión manual de estas cosas será menos trabajo que mantener una solución de colas separada.

Ewan
fuente
5

Como otros han mencionado, la escala probablemente no sea importante aquí. El problema con el uso de dos mecanismos de almacenamiento diferentes es la integridad transaccional.

Si va con una cola de mensajes dedicada, debe elegir una de las siguientes opciones en caso de falla.

  1. Permitir que los datos puedan estar en mb pero no en db
  2. Permitir que los datos puedan estar en db pero no en mb
  3. Configure transacciones de confirmación o distribuidas en dos fases entre db y mq que pueden ser complicadas

Todos estos problemas desaparecen si solo guarda datos en un lugar utilizando una transacción normal. Por esta razón, usar db como una cola de tareas es una solución perfecta.

Esben Skov Pedersen
fuente
4

Por razones prácticas, las principales razones para utilizar una cola de mensajes son:

  • No tuve que reinventar la rueda. Diseñar incluso la cola de mensajes más simple utilizando una base de datos requiere al menos un par de horas de reflexión, algunas horas de codificación, etc. En comparación con la implementación de una cola de mensajes, el tiempo requerido para configurar y / o automatizar la configuración es trivial
  • Las colas de mensajes tienen una interfaz agradable y clara para el productor y el consumidor. Esto es probablemente lo más importante en la aplicación de escritura. Sin la interfaz, las colas de mensajes son básicamente solo una recopilación de datos
  • Las colas de mensajes ofrecen más funciones que podrían ser necesarias en el futuro.

En cuanto a permitir que los usuarios elijan, ese es realmente un detalle de implementación que a los usuarios no debería importarles. Los usuarios deberían tener la misma interfaz y no debería haber diferencia para los usuarios si se utiliza la base de datos o la cola de mensajes. Una vez que se establece un diseño único, una opción probable para los usuarios es cuántos nodos deben implementarse para satisfacer sus necesidades.

imel96
fuente
1

He creado una solución de cola de mensajes Mssql que puede manejar 20k operaciones por segundo, de acuerdo con una prueba de rendimiento, y necesitamos 10 / seg la mayor parte del tiempo. Creo que el hecho de que pueda tener prioridad incorporada es una característica de la que carece la cola de mensajes dedicada. Y este fue un requisito importante en mi caso.

Stephan Ryer
fuente