2012-04-14 28 views
8

Básicamente, mis consumidores también son productores. Obtenemos un conjunto de datos inicial y se envía a la cola. Un consumidor toma un elemento y lo procesa, a partir de ese momento hay 3 posibilidades:¿Es posible garantizar que los mensajes únicos estén en una cola rabbitmq?

  1. datos son buenos y se pone una 'buena' cola de almacenamiento
  2. de datos es mala y se desecha
  3. de datos no es bueno (todavía) o malo (aún), por lo que los datos se dividen en partes más pequeñas y se envían nuevamente a la cola para su posterior procesamiento.

Mi problema es con el paso 3, porque la cola crece muy rápido al principio es posible que un dato se descomponga en una parte que se duplique en la cola y los consumidores continúen procesándolo y terminen en un bucle infinito

Creo que la manera de evitar esto es evitar que los duplicados entren en la cola. No puedo hacer esto en el lado del cliente porque en el transcurso de una hora puedo tener muchos núcleos que manejan miles de millones de puntos de datos (hacer que cada cliente lo analice antes de enviarlo me ralentizaría demasiado). Creo que esto debe hacerse por el lado del servidor, pero, como mencioné, los datos son bastante grandes y no sé cómo asegurar de manera eficiente que no haya duplicados.

Podría estar preguntando lo imposible, pero pensé que le daría una oportunidad. Cualquier idea sería muy apreciada.

Respuesta

2

El problema principal parece ser la siguiente:

"...its possible that a piece of data is broken down into a part that's 
duplicated in the queue and the consumers continue to process it and 
end up in a infinite loop." 

Usted puede centrarse en la singularidad de sus elementos en cola todos los que quieran, pero el problema anterior es donde se debe enfocar sus esfuerzos, la OMI. Una forma de prevenir el bucle infinito podría ser tener un bit "visitado" en la carga útil de su mensaje que los consumidores establezcan antes de volver a poner en cola el elemento desglosado.

Otra opción sería hacer que los consumidores vuelvan a cola a una cola especial que se trata de forma ligeramente diferente para evitar el bucle infinito. De cualquier manera, debe atacar el problema al tratarlo como una parte central de la estrategia de su aplicación en lugar de utilizar una característica de un sistema de mensajería para evitarlo.

+0

Estoy tratando de hacer exactamente eso (creo). Al asegurar que no haya duplicados de artículos pasados, me aseguro de que los mismos datos no se procesen más de una vez. Estoy seguro de la implementación en rabbitmq, ¿hay alguna manera de simplemente enviar identificaciones de mensajes y tener rabbitmq descartar duplicados o tengo que establecer un filtro o algo así (si lo hago, ¿cómo funciona con rabbitmq). –

+0

No hay forma de hacerlo, AFAIK. A Rabbit no le importa el contenido de tus mensajes o lo que ya está en tus colas, por lo que dependerá de tu aplicación que te encargues de esto. –

+0

Entonces, si los ID de mis mensajes son únicos (hashcode de mis datos reales), necesitaría almacenarlos en un DB o algo así y consultar en contra de eso (para ver si ID de msg se envió antes) antes de enviarlo a rabbit He estado pensando en eso, pero requeriría que el cliente haga algunas consultas mientras mi servidor de mensajes espera (estaba tratando de ver si podía enviar este trabajo al servidor de mensajes en sí) –

8

creo que incluso si se pudiera solucionar el problema de no enviar duplicados a la cola, que tarde o temprano golpear a este tema:

De RabbitMQ Documentación: "La recuperación de fallos: en caso de que una el cliente está desconectado del intermediario debido a una falla del nodo al cual el cliente estaba conectado; si el cliente era un cliente de publicación, es posible que el intermediario haya aceptado y transmitido los mensajes del cliente sin que el cliente haya recibido la confirmación para ellos , y del lado de los consumidores, es posible que el cliente haya emitido reconocimientos por los mensajes y no tenga ni idea de si esos reconocimientos llegaron o no al intermediario y se procesaron antes de la falla. ocurrió. En resumen, usted todavía tiene que asegurarse de que sus clientes consumen pueden identificar y tratar con los mensajes duplicados."

Básicamente, parece que esto, se envía una solicitud a RabbitMQ, RabbitMQ responde con un ACK pero para 1 razón u otro, su consumidor o productor no recibe este ACK. Rabbitmq no tiene manera de saber que el acuse de recibo no fue recibido y su productor terminará reenviando el mensaje, nunca habiendo recibido un acuse de recibo.

Es un dolor manejar los mensajes duplicados, especialmente en aplicaciones donde los mensajes se utilizan como una especie de RPC, pero parece que esto es inevitable cuando se utiliza este tipo de arquitectura de mensajería.

Cuestiones relacionadas