RabbitMQ小记（一）——消息确认和消息持久化

Message acknowledgment（消息确认）

完成一项任务需要几秒钟。您可能想知道，如果其中一个使用者启动了一个很长的任务，但执行过程中挂了，只完成了部分任务，那么会发生什么情况。Spring AMQP 默认采用保守的消息确认方法。如果侦听器抛出异常，容器调用:

channel.basicReject(deliveryTag, requeue)

默认情况下，Requeue（重新分配到指定输出队列中） 为 true，除非您显式设置:

defaultRequeueRejected=false

或者侦听器抛出 AmqpRejectAndDontRequeueException。这通常是您希望从侦听器获得的行为。在这种模式下，没有必要担心被遗忘的确认。处理消息后，监听器调用:

channel.basicAck()

确认必须在接收交付的同一通道上发送。尝试确认使用不同的通道将导致通道级协议异常。有关确认的更多信息，请参阅文档指南。Spring AMQP通常负责这方面的工作，但是在与直接使用RabbitMQ Java客户机的代码一起使用时，需要记住这一点。

Message persistence（消息持久化）

默认情况下，Spring AMQP 中的消息是持久的。请注意，消息最终所在的队列也需要是持久的，否则消息将无法在代理重新启动时生存，因为非持久队列本身无法在重新启动时生存。

关于消息持久性的说明
将消息标记为持久并不能完全保证消息不会丢失。虽然它告诉 RabbitMQ 将消息保存到磁盘，但是当 RabbitMQ 接受了一条消息并且还没有保存它时，仍然还有一段很短的时间。此外，RabbitMQ并不对每条消息都执行 fsync(2) —— 它可能只是被保存到缓存中，而不是真正写到磁盘上。持久性保证并不强，但对于我们的简单任务队列来说已经足够了。如果您需要更强的保证，那么您可以使用 publisher confirm。