RabbitMQ中的Ack或Nack [英] Ack or Nack in rabbitMQ

问题描述

我正在使用RabbitMQ，我使用basic_get从队列中提取了所有消息，而没有自动确认过程，这意味着消息会一直保留在队列中，直到我确认或否定消息为止.

I'm using rabbitMQ, I take every message from queue with basic_get without automatically acking procedure, which means the message remain in queue until I ack or nack the message.

有时我收到的消息由于抛出某些异常而无法处理，从而导致无法完全处理它们.

Sometimes I've messages that can't be processed because of some exception thrown, which prevented them from being fully processed.

问题是，如果我都成功确认消息并抛出异常，那有什么关系，我的意思是，结果消息将始终脱离队列，因此，在这种情况下，如果我使用ack或nack怎么办? ? 也许我错过了每次使用手术时的一些东西?

Question is what does it matter if I both ack the messages in success and exception thrown, I mean in terms of result messages will always get out of the queue, so what does it matter if I use ack or nack in this scenario? Maybe I miss something about when using each opration?

推荐答案

basic.nack 命令显然是RabbitMQ扩展，扩展了

The basic.nack command is apparently a RabbitMQ extension, which extends the functionality of basic.reject to include a bulk processing mode. Both include a "bit" (i.e. boolean) flag of requeue, so you actually have several choices:

• nack/reject和requeue=1:消息将被返回到它来自的队列，就好像它是一条新消息一样；如果消费者方面暂时出现故障，这可能会很有用
• nack/reject与requeue=0和已配置的死信交换(DLX)，会将消息发布到该交换，从而允许它被另一个队列接收
• nack/reject和requeue=0，没有DLX会简单地丢弃该消息
即使已配置DLX，
• ack也会从队列中删除消息

• nack/reject with requeue=1: the message will be returned to the queue it came from as though it were a new message; this might be useful in case of a temporary failure on the consumer side
• nack/reject with requeue=0 and a configured Dead Letter Exchange (DLX), will publish the message to that exchange, allowing it to be picked up by another queue
• nack/reject with requeue=0 and no DLX will simply discard the message
• ack will remove the message from the queue even if a DLX is configured

如果未配置DLX，则始终使用ack与nack/reject和requeue=0相同；但是，从一开始就使用逻辑上正确的功能将为您提供更大的灵活性，以便以后进行不同的配置.

If you have no DLX configured, always using ack will be the same as nack/reject with requeue=0; however, using the logically correct function from the start will give you more flexibility to configure things differently later.

这篇关于RabbitMQ中的Ack或Nack的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！