instalar - Cómo volver a poner mensajes en RabbitMQ

rabbitmq tutorial (1)

Después de que el consumidor recibe un mensaje, el consumidor / trabajador realiza algunas validaciones y luego llama al servicio web. En esta fase, si ocurre algún error o falla la validación, queremos que el mensaje vuelva a la cola de la que se consumió originalmente.

He leído la documentación de RabbitMQ. Pero estoy confundido acerca de las diferencias entre los métodos de rechazo, nack y cancelación.

Respuesta corta:

Para volver a poner en cola un mensaje específico, puede elegir tanto basic.reject como basic.nack con multiple basic.nack establecidas en falso.

basic.consume llamadas también pueden dar lugar a una basic.consume entrega de mensajes si está utilizando el reconocimiento de mensajes y hay un mensaje no reconocido en el consumidor en el momento específico y la salida del consumidor sin reconocerlos.

basic.recover volverá a basic.recover todos los mensajes no recibidos en un canal específico.

Respuesta larga:

basic.reject y basic.nack sirven para el mismo propósito: enviar o reenviar un mensaje que no puede ser manejado por un consumidor específico (en el momento dado, bajo ciertas condiciones o en absoluto). La principal diferencia entre ellos es que basic.nack admite el procesamiento masivo de mensajes, mientras que basic.reject no lo hace.

Esta diferencia se describe en el artículo de Reconocimientos Negativos en el sitio web oficial de RabbitMQ:

La especificación AMQP define el método basic.reject que permite a los clientes rechazar mensajes individuales entregados, indicando al agente que los descarte o los vuelva a poner en cola. Desafortunadamente, basic.reject no ofrece soporte para el reconocimiento negativo de mensajes en masa.
Para resolver esto, RabbitMQ admite el método basic.nack que proporciona toda la funcionalidad de basic.reject al mismo tiempo que permite el procesamiento masivo de mensajes .
Para rechazar mensajes de forma masiva, los clientes establecen el indicador multiple del método basic.nack en true . El agente luego rechazará todos los mensajes no reconocidos y entregados hasta el mensaje especificado en el campo delivery_tag del método basic.nack . A este respecto, basic.nack complementa la semántica de reconocimiento masivo de basic.ack .

Tenga en cuenta que el método basic.nack es una extensión específica de RabbitMQ, mientras que el método basic.reject forma parte de la especificación AMQP 0.9.1.

En cuanto al método basic.cancel , se utiliza para notificar al servidor que el cliente deja de consumir mensajes. Tenga en cuenta que el cliente puede recibir un número de mensajes arbitrarios entre el método basic.cancel que envía una respuesta de cancel-ok . Si el cliente utiliza el reconocimiento de mensajes y tiene algún mensaje no reconocido, se moverán nuevamente a la cola de la que se consumieron originalmente.

basic.recover tiene algunas limitaciones en RabbitMQ: it - basic.recover with requeue = false - basic.recover synchronicity

Además de la errata, de acuerdo con las especificaciones de RabbitMQ, basic.recover tiene soporte parcial (no se admite la recuperación con requeue = false).

Nota sobre basic.consume :

Cuando basic.consume inició sin auto-ack ( noack=false ) y hay algunos mensajes pendientes que no están marcados, luego cuando el consumidor se cancela (muere, error fatal, excepción, lo que sea), los mensajes pendientes se volverán a entregar. Técnicamente, los mensajes pendientes no se procesarán (incluso con letra muerta) hasta que el consumidor los libere (ack / nack / reject / recover). Sólo después de eso serán procesados (por ejemplo, deadlettered).

Por ejemplo, digamos que originalmente publicamos 5 mensajes seguidos:

Queue(main) (tail) { [4] [3] [2] [1] [0] } (head)

Y luego consuma 3 de ellos, pero no los acepte, y luego cancele al consumidor. Tendremos esta situación:

Queue(main) (tail) { [4] [3] [2*] [1*] [0*] } (head)

donde la estrella ( * ) señala que el indicador redelivered establece en true .

Supongamos que tenemos una situación con el conjunto de intercambio de letras muertas y la cola para los mensajes de letras muertas

Exchange(e-main) Exchange(e-dead) Queue(main){x-dead-letter-exchange: "e-dead"} Queue(dead)

Y supongamos que publicamos 5 mensajes con la propiedad expire establecida en 5000 (5 s):

Queue(main) (tail) { [4] [3] [2] [1] [0] } (head) Queue(dead) (tail) { }(head)

y luego consumimos 3 mensajes de la cola main y los mantenemos durante 10 segundos:

Queue(main) (tail) { [2!] [1!] [0!] } (head) Queue(dead) (tail) { [4*] [3*] } (head)

donde el signo de exclamación ( ! ) significa mensaje sin apilar. Dichos mensajes no se pueden entregar a ningún consumidor y normalmente no se pueden ver en el panel de administración. Pero cancelemos al consumidor, recuerde, que todavía tiene 3 mensajes sin aviso:

Queue(main) (tail) { } (head) Queue(dead) (tail) { [2*] [1*] [0*] [4*] [3*] } (head)

Así que ahora, los 3 mensajes que estaban en la cabecera se devolvieron a la cola original, pero como tienen un conjunto de TTL por mensaje, tienen una letra muerta en la cola de la cola de la letra muerta (claro, a través del intercambio de la letra muerta).

PD:

Consumir un mensaje conocido como escuchar uno nuevo es de alguna manera diferente del acceso directo a la cola (obtener uno o más mensajes sin cuidar de los demás). Vea la descripción del método basic.get para más información.