Confundido en cuanto a cuándo utilizaría JMS (o una cola en general) frente a una base de datos

Question

Cuando almacena un mensaje en una cola, ¿no es más información de metadatos que quien tira de la cola sabe cómo procesar el ¿datos? la información real en la cola no siempre contiene toda la información.

Digamos que tiene una aplicación como Twitter, cada vez que alguien publica un mensaje, ¿aún necesita almacenar el mensaje de texto real en la base de datos correcta?

La cola se usaría más para transmitir a otros suscriptores que ha llegado un nuevo mensaje, y luego esos servicios podrían tomar otras medidas.

¿O podría realmente almacenar el texto del tweet en la cola también? (o PODRÍA, pero sería una tontería?)

¿Podría un mensaje de cola tener campos de estado, que los suscriptores pueden cambiar a medida que procesan su parte del flujo de trabajo? (o lo haría en el archivo db?)

Solo estoy tratando de obtener una aclaración de cuándo utilizaría una cola en lugar de db.

Answer 1

Cuando un proceso quiere datos de la comunidad y el procesamiento de esos datos a otro proceso (posiblemente en un host diferente), hay 2 estrategias:

1. Stuff todos sus datos en el elemento de cola y deje que la aplicación receptora se preocupe por guardarla en la base de datos, entre cualquier otro procesamiento.

2. Actualice su base de datos, y luego coloque en cola un pequeño mensaje al otro proceso simplemente para notificarle que hay nuevos datos para ser masajeados.

Hay una serie de factores que pueden ser utilizados para decidir sobre qué estrategia:

• Si su base de datos es totalmente ÁCIDO (es de esperar), pero el sistema de colas (QS) no es , sus datos estarían más seguros en la base de datos. Incluso si el mensaje de la cola se pierde en un bloqueo del servidor, puede ejecutar un script para procesar los datos no procesados ​​que se encuentran en el DB. Este sería un caso para la opción 2.

• Si sus datos son bastante grandes (digamos, 1 MB o más), entonces podría ser cruel cargar su QS con él. Si es persistente, terminará escribiendo los datos dos veces, primero en la persistencia del QS y luego en el DB. Esto podría ser un lastre para el rendimiento e influir en que vaya por la opción 1.

• Si su base de datos es lenta o no es accesible para la interfaz de su aplicación, entonces la opción 1 sí lo es.

• Si su segundo proceso va a hacer algo con los datos pero no lo almacena en un DB, entonces la opción 1 puede ser el camino a seguir.

No se me ocurre nada más, pero espero que entiendas la idea.

Answer 2

Creo que su ejemplo de Twitter es bueno. Desea la base de datos para datos a largo plazo. No tendría sentido poner el tweet en el mensaje porque tiene que ir a la base de datos. Sin embargo, si estuviera ejecutando una sala de chat, puede continuar y colocar el mensaje en la cola JMS porque no la está almacenando a largo plazo en ninguna parte.

No es que no pueda poner el tweet en el JMS sino que necesita ponerlo en la base de datos de todos modos.

Answer 3

Le recomiendo que consulte el libro de Gregor Hophe, Enterprise Integration Patterns, que explica muchos patrones diferentes para los enfoques basados ​​en mensajes.

Answer 4

En general, una cola se utiliza para 'suavizar' la tasa de publicación frente a la tasa de consumo, almacenando en búfer las solicitudes entrantes que no se pueden manejar de inmediato. Una cola generalmente está respaldada por algún tipo de almacenamiento no volátil (como una tabla de base de datos). Entonces la distinción no es tan clara.

Use una base de datos cuando desee realizar muchas búsquedas en su "cola" o proporcione informes detallados.

Answer 5

Usaría la cola siempre que pueda utilizar un patrón de "fuego y olvídate". En su ejemplo de Twitter, usaría la cola para publicar el mensaje del cliente. El procesador de cola puede almacenarlo en la base de datos cuando llegue a él.

Si necesita algún tipo de estado de éxito/falla inmediata, entonces la cola de mensajes no es para usted.

Answer 6

Utilizamos mucho JMS en mi último trabajo en el que transmitíamos datos de una máquina a otra. Al final, ambos estábamos enviando y almacenando los datos al mismo tiempo; sin embargo, almacenamos mucha menos información de la que enviamos. Tuvimos muchos metadatos alrededor de los valores reales.

Utilizamos JMS simplemente como un servicio de mensajería y funcionó muy bien para eso. Pero no desea usar JMS para almacenar sus datos ya que no tiene persistencia (aparte de poder registrar y reproducir los mensajes quizás).

Una de las principales ventajas que JMS le brinda es la capacidad de enviar sus mensajes en el orden correcto y apropiado y asegurarse de que todos los reciban en ese orden. Esto facilita la sincronización ya que la mayoría del manejo de mensajes se hace por usted.

Answer 7

Según entiendo, Twitter utilizará tanto DB como JMS en conjunto. Primero, cuando se escriban los tweets, los almacenará en la base de datos y así se mostrará en el tablero de mensajes. Sin embargo, dado que este es un modelo de editor/suscriptor cuando se publican los tweets, se enviará a los suscriptores. Entonces ambos elementos serán usados.