总览
- 为什么需要确认
- 手动和自动确认模式
- 确认API[多次确认和重新排队]
- 连接丢失或通道关闭时自动重新排队
- 通道预取及其对吞吐量的影响
- 最常见的客户错误
- 发布者确认和相关发布者数据安全主题
基础
按照定义，使用消息传递代理(RabbitMQ)的系统是分布式的。由于不能保证发送的消息可以到达对方或者被其成功处理，因此发布者和消费者都需要一种机制来进行传递和处理确认。
从消费者到RabbitMQ的消息确认被称为消息传递协议的确认
对发布者的去人称为发布者确认。两种功能都基于相同的思想，启发于TCP.
这对于 发布者到RabbitMQ,RabbitMQ到消费者的可靠交付都是必不可少的。 他们对于数据安全至关重要。
消费者确认
RabbitMQ 将消息传递给使用者的时候，需要知道何时消息被处理成功。具体逻辑取决于系统。因此这个是应用程序的决策.
确认标识
确认消息，重要的是如何识别确认的消息。
注册 消费者后（订阅），RabbitMQ使用 basic.deliver 方法推送消息。该方法带有传递标签，该标签唯一标识通道上的传递。因此交付标签按通道划分范围
交付标签是单调的正整数，并有客户端库标识，确认交付的客户端库方法将交付标签作为参数
由于传递
- basic.ack 用于确认
- basic.nack 用于否定确认
- basic.reject 用于否定确认，但与basic.nack 相比有一个限制
自动确认模式：
消息视为发送后立即成功传递。这种模式需要权衡更高的吞吐量(只要消费者可以跟上),以降低交付和消费者处理的安全性。此模式通常称为“一劳永逸”。和手动确认模式不同，如果在成功传递前关闭了TCP连接或者通道，则服务器发送的消息将丢失。因此，自动消息确认应该被认为是不安全的，并且不适合所有有负载的工作。
一次确认多个
处理网络流量考虑