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.
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?
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/rejectwithrequeue=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 sidenack/rejectwithrequeue=0and a configured Dead Letter Exchange (DLX), will publish the message to that exchange, allowing it to be picked up by another queuenack/rejectwithrequeue=0and no DLX will simply discard the messageackwill remove the message from the queue even if a DLX is configured
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.
Ack and Nack both remove the message from the queue, the difference is that when you Nack a message it goes into the DLX (dead letter queue) if there is one defined for that queue.
来源：https://stackoverflow.com/questions/28794123/ack-or-nack-in-rabbitmq