Lo busqué y solía enviar mensajes entre 2 sistemas.
¿Pero por qué? ¿Por qué no usarías simplemente un Database?
¿Debe haber alguna característica que no ActiveMQtenga Databases?
Respuestas:
Se utiliza para comunicarse de manera confiable entre dos procesos distribuidos.
Sí, podría almacenar mensajes en una base de datos para comunicarse entre dos procesos, pero, tan pronto como se reciba DELETEel mensaje, tendrá que ver el mensaje, eso significa una fila INSERTy DELETEpara cada mensaje.
Cuando intentas escalar eso comunicando miles de mensajes por segundo, las bases de datos tienden a caer .
Los middleware orientados a mensajes [MOM], como ActiveMQpor otro lado, están diseñados para manejar esos casos de uso.
Asumen que los mensajes en un sistema saludable se eliminarán muy rápidamente y pueden hacer optimizaciones para evitar la sobrecarga .
También puede enviar mensajes a los consumidores en lugar de que un consumidor tenga que sondear el nuevo mensaje mediante una consulta SQL.
Esto reduce aún más la latencia involucrada en el procesamiento de nuevos mensajes que se envían al sistema.
ActiveMQ, o en general, todas las implementaciones de Middleware orientado a mensajes (MOM) están diseñadas con el propósito de enviar mensajes entre dos aplicaciones o dos componentes dentro de una aplicación.
Esencialmente, MOM y las bases de datos comparten una base común en el sentido de que brindan almacenamiento de datos transaccionales y persistentes para leer y escribir.
La gran diferencia es el patrón de uso: donde las bases de datos son muy genéricas y optimizadas para búsquedas complejas en múltiples tablas, MOM está optimizado para leer mensajes, uno a la vez, en un formato FIFO como [Cola].
JMS, que es una API que implementa ActiveMQ, es una piedra angular importante en las aplicaciones Java Enterprise. Esto hace que los mensajes compartan un formato y una semántica bastante comunes, lo que facilita la integración entre diferentes aplicaciones.
Por supuesto, hay una gran cantidad de características más detalladas que se encuentran sólo en ActiveMQ, protocolos de alambre como OpenWire, STOMPy MQTT, JMS, EIPjunto con Apache Camel, patrones de mensajes como "petición / respuesta" y "publicación / suscripción", JMS Bridging, la agrupación (" red de corredores "), que permiten escalado y distribuciones, etc.
Debería leer un poco sobre esos temas si está interesado ya que son bastante extensos.
ActiveMQtiene un excelente soporte de programación , lo que significa que puede programar el envío de su mensaje para que se entregue en un momento particular .
Hemos utilizado esta función para enviar recordatorios de medicamentos a los pacientes que cargan los detalles de sus medicamentos en un escenario de atención médica.
Scheduled Jobsde datos de Oracle para los mismos fines.
Con RDBMS, cuando procesa una fila de datos, normalmente actualiza una marca que indica que la fila se ha procesado para que el procesamiento no se repita.
Sin embargo, con Message Queue, solo tiene que reconocer un mensaje y el próximo consumidor procesará el siguiente.
La diferencia es que la UPDATEdeclaración en un RDBMS es una operación realmente lenta en comparación con la acknowledgede activmeq.
me gustaría enfatizar lo siguiente:
Desacoplado : los sistemas pueden comunicarse sin estar conectados. La cola se encuentra entre los sistemas, una falla del sistema nunca afectará al otro ya que la comunicación se realiza a través de la cola. Los sistemas continúan funcionando cuando están activos.
Soporte de recuperación : los mensajes en las colas persistieron. Los mensajes se pueden restaurar más tarde si la cola falla.
Comunicación confiable : considere un sistema que procese las solicitudes de los clientes. En casos normales, el sistema recibe 100 solicitudes por minuto. Este sistema no es confiable cuando el número de solicitudes supera el promedio. En tal caso, Queue puede administrar solicitudes y puede enviar mensajes periódicamente según el rendimiento del sistema sin interrumpirlo.
Asíncrono : la comunicación entre el cliente y el servidor no se bloquea. Una vez que el cliente envía la solicitud al servidor, puede realizar otras operaciones sin esperar respuesta. Cuando la respuesta recibida, el cliente puede manejarla en cualquier momento.
De Wikipedia
Apache ActiveMQ es un agente de mensajes de código abierto escrito en Java junto con un cliente completo de Java Message Service (JMS). Proporciona "Funciones empresariales" que en este caso significa fomentar la comunicación desde más de un cliente o servidor.
Respecto a sus consultas:
¿Por qué no usarías una base de datos?
Debe usar la base de datos para datos persistentes y no para datos temporales. Suponga que tiene que enviar un mensaje del remitente al receptor. Al recibir el mensaje, Receiver ejecuta una operación (recibir, procesar y olvidar). Después de procesar ese mensaje, no necesita ese mensaje en absoluto. En este caso, almacenar el mensaje en una base de datos persistente no es una solución adecuada.
Estoy totalmente de acuerdo con la respuesta de @Hiram Chirino con respecto a la inserción y eliminación de mensajes en la base de datos si usa la base de datos en lugar del sistema de mensajería.
Beneficios de esto artículo y este artículo
¿Debe haber una característica que ActiveMQ tenga que las bases de datos no?
Hay muchos. Eche un vistazo a la página de documentación para obtener más detalles. Mira esto los casos de uso .
Eche un vistazo a esta presentación para comprender los aspectos internos de ActiveMQ.
Suponga que tiene una aplicación que se utiliza en varias ubicaciones al mismo tiempo. También suponga que su aplicación tiene que manejar miles de solicitudes por minuto o algo así para que las operaciones normales de la base de datos no puedan manejar dichas operaciones, Activemq actúa como el procesamiento de mensajes, lleva todos los mensajes a la cola, por lo que incluso si una de sus aplicaciones falla en una ubicación la otra ubicación no se verá afectada.