¿Cómo configuro una cantidad de bashs de rebash en RabbitMQ?

Estoy usando RabbitMQ y tengo una cola que contiene mensajes de correo electrónico. Mi servicio al consumidor elimina los mensajes e intenta enviarlos. Si, por algún motivo, mi consumidor no puede enviar el mensaje, me gustaría volver a ponerlo en cola para enviarlo nuevamente. Me doy cuenta de que puedo hacer un BasicNack y establecer que el indicador de reabastecimiento sea verdadero, sin embargo, no quiero volver a poner el mensaje indefinidamente (por ejemplo, si nuestro sistema de correo electrónico falla, no quiero volver a cargar continuamente los mensajes no enviados). Me gustaría definir un número finito de veces que puedo volver a colocar el mensaje para enviarlo nuevamente. Sin embargo, no puedo establecer un campo en el objeto de mensaje de correo electrónico cuando lo dequeo y envío un nack. El campo actualizado no está presente en el mensaje en la cola. ¿Hay alguna otra manera en que pueda abordar esto? Gracias por adelantado.

No hay ninguna característica como los bashs de rebash en RabbitMQ (ni en el protocolo AMQP).

La posible solución para implementar el bash de rebash limita el comportamiento:

  1. basic.deliver a basic.deliver el mensaje si no se volvió a entregar anteriormente (compruebe el parámetro redelivered en el método basic.deliver : su biblioteca debe tener alguna interfaz para esto) y suéltelo, luego capture en el intercambio de letras muertas y luego procese de algún modo.

  2. Cada vez que el mensaje no se puede procesar, publíquelo de nuevo, pero configure o incremente / disminuya el campo del encabezado, digamos x-redelivered-count (sin embargo, puede elegir el nombre que desee). Para tener control sobre las entregas nuevas, en este caso debe verificar el campo que establece si alcanza algún límite (arriba o abajo, 0 es mi elección, a-la ttl en el encabezado ip desde tcp / ip).

  3. Almacene la clave única del mensaje (digamos uuid, pero debe configurarla manualmente cuando publique el mensaje) en Redis, Memcache u otro almacenamiento, incluso en mysql junto con el recuento de las entregas y luego en cada incremento / decremento de este valor hasta que scope el límite .

  4. (para geeks geniales) escribir el plugin que implementará tal comportamiento como lo desee.

El pro del # 3 es que el mensaje reenviado se queda en el encabezado de la cola. Esto es importante si tiene una cola larga o si el orden de los mensajes es importante para usted (tenga en cuenta que las entregas romperán el orden estricto de los mensajes, consulte los documentos oficiales para obtener detalles o esta pregunta en SO ).

PD:

Hay una respuesta similar en este tema, pero en php. Mire a través de él, tal vez lo ayude un poco (comience a leerlo con las palabras “Existen múltiples técnicas para lidiar con el problema de redistribución del ciclo”) .