Pregunta

He estado experimentando los aspectos positivos y negativos de los sistemas de mensajería en entornos de producción reales , y debo admitir que una tabla o esquema de tablas bien organizados simplemente supera cada vez que cualquier otra forma de Cola de mensajes, porque:

  1. Los datos se almacenan permanentemente en una tabla. He visto muchas aplicaciones java (jms) que pierden o desaparecen mensajes en su camino por excepciones no detectadas u otros errores.
  2. Las colas tienden a llenarse. En cambio, el almacenamiento de datos es prácticamente infinito.
  3. Las tablas son fácilmente accesibles, mientras que tienes que usar instrumentos esóticos para leer de una cola.

¿Cuál es tu opinión sobre cada enfoque?

¿Fue útil?

Solución

La frase late cada vez depende totalmente de cuáles fueron sus requisitos para comenzar. Ciertamente, no se va a superar cada vez para todos.

Si está creando un sistema único que ya está utilizando una base de datos, no tiene requisitos de rendimiento de rendimiento muy altos y no tiene que comunicarse con ningún otro equipo o sistema, entonces probablemente tenga razón.

Para una base de datos simple, baja, en su mayoría de un solo hilo, la base de datos es una alternativa totalmente excelente a las colas de mensajes.

Donde brilla una cola de mensajes es cuando

  • desea un equilibrador de carga escalable, altamente concurrente y de alto rendimiento para que pueda procesar decenas de miles de mensajes por segundo a la vez en varios servidores / procesos (si utiliza una tabla de base de datos, tendrá la suerte de procesar unos pocos cientos por segundo y procesar con varios subprocesos es bastante difícil ya que un proceso tenderá a bloquear la tabla de cola de mensajes)
  • necesita comunicarse entre diferentes sistemas utilizando diferentes bases de datos (así que no tiene que entregar el acceso de escritura a la base de datos de su sistema a otras personas en diferentes equipos, etc.)

Para sistemas simples con una sola base de datos, equipo y requisitos de rendimiento bastante modestos, asegúrese de usar una base de datos. Utilice la herramienta adecuada para el trabajo, etc.

Sin embargo, donde las colas de mensajes brillan es en organizaciones grandes donde hay muchos sistemas que necesitan comunicarse entre sí (y por lo tanto no desea que una base de datos empresarial sea un punto central de falla o lugar de la versión del infierno) o cuando tienes requisitos de alto rendimiento.

En términos de rendimiento, una cola de mensajes siempre vencerá una tabla de base de datos, ya que las colas de mensajes están diseñadas específicamente para el trabajo y no dependen de bloqueos de tabla pesimistas (que son necesarios para la implementación de una cola en la base de datos) para hacer la balanceo de carga) y las buenas colas de mensajes realizarán una gran carga de mensajes en las colas para evitar la sobrecarga de red de una base de datos .

Del mismo modo, nunca usaría una base de datos para realizar el equilibrio de carga de las solicitudes HTTP en sus servidores web, ya que sería demasiado lento, si tiene altos requisitos de rendimiento para su equilibrador de carga, tampoco usaría una base de datos .

Otros consejos

Primero he usado tablas, luego refactorizo ??a una cola de mensajes completos cuando (y si) hay una razón, lo cual es trivial si su diseño es razonable.

Los mayores beneficios son: Las herramientas de Message Queue, d.) Es generalmente un poco más fácil configurar un entorno de prueba / dev en un contexto que ya existe para su aplicación (si se aplica la misma familiaridad).

Ah, y e.) para tal vez usted y otros, no es otro producto para aprender, instalar, configurar, administrar y dar soporte.

IMPE, es igual de confiable, desconectable y se puede convertir si necesita más escalable.

  1. Los datos se almacenan permanentemente en una tabla. He visto muchas aplicaciones java (jms) que pierden o desaparecen mensajes en su camino por excepciones no detectadas u otros errores.

    ¿Qué implementación de JMS? Sun vende una cola confiable que no puede perder mensajes. Tal vez usted acaba de comprar un producto que cumple con JMS. La MQ de IBM es extremadamente confiable y hay bibliotecas JMS para acceder a ella.

  2. Las colas tienden a llenarse. En cambio, el almacenamiento de datos es prácticamente infinito.

    Ummm ... Si tu cola se llena, parece que algo está roto. Si sus aplicaciones fallan, eso no es bueno, y las colas tienen poco que ver con eso. Si ha adquirido una implementación JMS realmente deficiente, puedo ver dónde puede estar descontento con ella. Es un mercado competitivo. Encuentra un mejor gestor de colas. El JCAPS de Sun tiene un muy buen administrador de colas, anteriormente la cola de mensajes de SeeBeyond.

  3. Las tablas son fácilmente accesibles, mientras que tienes que usar instrumentos esóticos para leer de una cola.

    Eso no encaja con mi experiencia. Se accede a las tablas a través de este peculiar "otro idioma" (SQL), y requiere que conozca las asignaciones de estructura de tablas a objetos y asignaciones de tipo de datos de VARCHAR2 a String Además, tengo que usar algún tipo de capa de acceso (JDBC o un ORM que usa JDBC). Eso parece muy, muy complejo. Se accede a una cola a través de MessageConsumers y MessageProducers utilizando envíos y recepciones simples.

Parece que los problemas que ha experimentado no son inherentes a la mensajería, sino que son artefactos de sistemas de mensajería mal implementados. ¿Es más difícil construir sistemas de mensajería que construir sistemas de bases de datos? Sí, si todo lo que haces es crear sistemas de bases de datos.

  • ¿Perdiendo mensajes a excepciones no detectadas? Eso no es culpa de la cola de mensajes. Las aplicaciones que estás utilizando están mal diseñadas. Están eliminando mensajes de la cola antes de que se complete el procesamiento. No están utilizando transacciones, ni diarios.
  • Las colas de mensajes se llenan mientras el almacenamiento de DB es " virtualmente infinito " ;? Se habla como si la administración de espacio en disco fuera algo que las bases de datos no requerían. Los servidores de colas de mensajes requieren administración, al igual que los servidores de bases de datos.
  • ¿Instrumentos esotéricos para leer de una cola? Tal vez si encuentras métodos asíncronos esotéricos. Tal vez si encuentras serialización y deserialización esotérica. (Al menos, esas son las cosas que encontré esotéricas cuando estaba aprendiendo mensajes. Como muchas tecnologías aparentemente esotéricas, en realidad son bastante mundanas una vez que las entiendes, y entenderlas es una parte importante de la educación de los desarrolladores experimentados). / li>

Aspectos de la mensajería que lo hacen superior a las bases de datos:

  • Procesamiento asíncrono. Las colas de mensajes notifican los procesos en espera cuando llegan nuevos mensajes. Para lograr esta funcionalidad en una base de datos, los procesos de espera tienen que sondear la base de datos.
  • Separación de inquietudes. El canal de comunicaciones está desacoplado de los detalles de la implementación del contenido del mensaje. Solo el remitente y el destinatario deben saber algo sobre el formato del flujo de datos dentro de un mensaje dado.
  • Tolerancia a fallos. La mensajería puede funcionar cuando las conexiones entre servidores son intermitentes. Las colas de mensajes pueden almacenar mensajes localmente y solo reenviarlos a servidores remotos cuando la conexión está activa.
  • Integración de sistemas. En el mundo de Windows, al menos, la mensajería está integrada en el sistema operativo. Utiliza el modelo de seguridad del sistema operativo, se administra a través de las herramientas del sistema operativo, etc.

Si no necesita estas cosas, es probable que no necesite mensajes.

Este es un ejemplo simple de una aplicación para mensajería: estoy creando un sistema en este momento donde los usuarios, distribuidos en múltiples redes, están ingresando a conjuntos de transacciones bastante complejas que se utilizan para producir resultados impresos. La generación de salida es computacionalmente costosa y no forma parte de su flujo de trabajo; es decir, a los usuarios no les importa cuándo se genera la salida, solo que sí.

Entonces, serializamos las transacciones en un mensaje y las colocamos en una cola. Un proceso que se ejecuta en un servidor toma mensajes de la cola, produce el resultado y almacena el resultado en un sistema de imágenes.

Si utilizáramos una base de datos como nuestro almacén de mensajes, tendríamos que crear un esquema para almacenar un formato de transacción que en este momento solo se preocupe por el remitente y el destinatario, deberíamos asegurarnos de que cada estación de trabajo en el la red tenía conexiones permanentes permanentes con el servidor de la base de datos, no tendríamos capacidad para distribuir esta carga de transacciones entre varios servidores, y nuestro servidor de salida tendría que consultar la base de datos miles de veces al día para ver si había nuevos trabajos para procesar .

Las colas proporcionan mensajes confiables. La naturaleza desconectada de almacenamiento y envío de la cola hace que sea mucho más escalable que las bases de datos, por no mencionar que es más robusto.

Y las colas no deberían usarse para el almacenamiento permanente de información, es mejor pensar en ellas como bandejas de entrada temporales, a diferencia de las bases de datos.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top