波斯马BOSSMA Information Technology

这篇文章翻译自：http://www.rabbitmq.com/confirms.html

译注：这里将Consumer Acknowledgements翻译为消费者应答，将Acknowledgement简称为Ack，Acknowledgement本意是应答或者承认，肯定的应答实际产生确认的效果。Publisher Confirms翻译为发布者确认，Confirm本意是通过再次检查确认某些事是正确的，但是RabbitMQ代理也可能向发布者返回消息接收失败。

引言

如果系统使用类似RabbitMQ这种分布式的消息代理，因为协议方法（消息）发送不保证到达节点或者被节点成功处理，所以发布者和消费者都需要某种机制来对投递和处理进行确认。RabbitMQ的一些消息协议支持这些功能。这篇指南将涵盖AMQP 0-9-1中的这些功能，其想法与其它一些协议（STOMP, MQTT等等）大致相同。

在AMQP 0-9-1中从消费者到RabbitMQ的投递处理确认被称为应答，代理对发布者的确认是一个协议扩展，称为发布者确认。

（消费者）投递应答

当RabbitMQ投递一条消息到消费者时，它需要知道什么时候认定消息已经成功发送。什么样的逻辑是最优的取决于业务系统。因此它主要是一个应用的决策。在AMQP 0-9-1 中，这个决策发生在当一个消费者使用basic.consume方法注册时，或者通过basic.get方法获取一条消息时。

如果你想要更多实例和按部就班的资料，RabbitMQ教程#2中涵盖了消费者应答。

投递标识符：投递标签（Tag）

在继续讨论其它主题之前，需要重点说明投递是怎样被标识的（以及应答声明他们各自对应的投递）。当消费者（订阅）注册后，RabbitMQ将使用basic.deliver方法投递（推送）消息。这个方法携带一个投递标签，在每个通道上可以唯一的标识一次投递。因此投递标签的作用域是每个通道。

投递标签是单调增长的正整数，由客户端类库提供。应答投递的客户端类库方法也使用投递标签作为参数。

Ack模式

依据使用的Ack模式，RabbitMQ认定消息被成功投递的时机，既可以在消息一经发送之后（已写到TCP Socket），也可以在收到明确的（手动的）客户端ACK时。使用下边的某个协议方法，手动发送的Ack可以是肯定的或者否定的：

• basic.ack用于肯定Ack
• basic.nack用于否定Ack（注：这是RabbitMQ对AMQP 0-9-1的扩展）
• basic.reject用于否定Ack，但是与basic.nack相比限制1条

肯定Ack简单的指示RabbitMQ记录一条消息已被投递。否定Ack使用basic.reject有相同的效果。不同的主要是语义：肯定Ack认为消息已经被成功处理，否定Ack则表明投递没有被处理但是仍然应该被删除。

一次应答多条投递

手动Ack可以采取批量处理的方式，以减少网络通信。这可以通过设置Ack方法中的multiple字段来完成。注意basic.reject中一直没有这个字段，这也是RabbitMQ将basic.nack作为一个协议扩展引入的原因。

当multiple字段被设置为true，RabbitMQ将应答所有未完成的投递标签，这些标签直到并包括在Ack中指定的标签。像其它所有与Ack有关的一样，它的作用域是每个通道。例如，在通道Ch中有几个未应答的投递标签5、6、7、8，当通道中有一个设置了delivery_tag为8和multiple为true的Ack帧到达时，所有从5到8的标签都将被确认。如果multiple被设置为false，投递5、6、7将仍然是未被应答的。

通道预取设置（QoS）

因为消息发送（推送）到客户端是异步的，所以在通道中某个给定的时刻经常有超过1条的消息在处理。此外，客户端发起的手动Ack也是天然异步的。因此对于未应答的投递标签有一个滑动窗口。开发者往往希望为这个窗口的大小增加一个限制，以避免消费者端的无限缓冲问题。这可以通过使用basis.qos方法设置prefetch count的值来实现。这个值定义了每个通道上允许的未应答投递的最大数量。一旦数量达到这个配置的值，RabbitMQ将停止在这个通道上投递更多的消息，除非有一个未完成的消息被应答。

例如，在通道Ch上有几个未应答的投递标签5、6、7、8，通道Ch的prefetch count设置为4，RabbitMQ将不会在Ch上推送更多的投递，除非其中某个未完成的投递被应答。当通道中有一个设置了delivery_tag为8的Ack帧到达时，RabbitMQ将会通知并再次投递消息。

需要反复重申的是投递和客户端手动Ack的流程是完全异步的。因此如果已经有投递在处理时prefetch的值被更改，将会出现紊乱情况，通道上未应答的消息数量可能临时的超过prefetch的值。

QoS设置可以为通道或者消费者配置。详情看消费者预取。

QoS设置对于使用basic.get（拉API）获取消息没有影响，即使是手动确认模式。

发布者确认（Confirm）

使用标准的AMQP 0-9-1，只有一个方法可以保证消息不丢失：使用事务，让通道具有事务性，发布消息，然后提交。在这种情况下，事务过于笨重，吞吐量会降低250倍。为了补救这个问题，一个确认机制被引入。它模仿协议中已经存在的消费者Ack机制。

为了使确认可用，客户端需要发送confirm.select方法。根据no-wait是否设置，代理可能会响应一个confirm.select-ok。一旦在通道上使用confirm.select方法，就可以说是确认模式。一个事务性的通道不能进入确认模式，一个确认模式的通道也不能成为事务性的。

一旦通道进入确认模式，代理和客户端都将计算消息总数（计算从第一次confirm.select从1开始）。代理处理消息时将通过在同一通道上发送一个basic.ack来确认消息。delivery-tag字段包含确认消息的序列号。代理也可能设置basic.ack的multiple字段，以指示所有消息已经被处理，这些消息直到并包括有序列号的这个。

有一个Java的例子：使用确认模式发布大量的消息到通道，然后等待确认。点击这里查看。

否定应答

在异常情况下，当代理不能成功处理消息时，代替basic.ack，代理将发送一个basic.nack。在此上下文中，basic.nack的字段与basic.ack相应的字段具有相同的含义，除了requeue字段应该被忽略。通过否定应答一条或多条消息，代理表示它不能处理这些消息，并且拒绝为这些消息负责；此时，客户端可能选择重新发布消息。

当通道进入确认模式，随后发布的所有消息都将被确认或者否定应答一次。不能保证消息确认的速度。消息将不能同时被确认和否定应答。

basic.nack将仅在负责某个队列的Erlang进程发生内部错误时被投递。

消息什么时候被确认？

对于不可路由的消息，代理将在交换机验证消息不能被路由到任何一个队列时（返回空的队列列表）发出一个确认。如果消息被发布为强制的，basic.return将在basic.ack之前发送到客户端。对于否定应答（basic.nack）也是如此。

对于可路由的消息，当消息被所有的队列接收后，代理将发送basic.ack。对于路由到持久化队列的持久化消息，这意味着持久化到磁盘。对于镜像队列，这意味着所有的镜像都已经接收了消息。

持久化消息的Ack延迟

对于路由到持久化队列的持久化消息，basic.ack将在持久化消息到磁盘后发送。RabbitMQ消息存储在某个时间间隔（几百毫秒）之后将消息批量保存到磁盘，以最大限度减少fsync(2)的调用次数，或者当队列空闲时。这意味着在恒定负荷下，basic.ack的延迟可以达到数百毫秒。为了提升吞吐量，强烈建议应用异步处理Ack，或者批量发布消息后等待未完成的确认。对于这些方式在客户端库中有明确的API。

发布者确认的排序考量

在大多数情况下，RabbitMQ将按照消息发布的顺序向发布者进行确认（这适用于消息都发布到一个通道的情况）。然而，发布者Ack是异步发出的，可以确认单条消息，也可以确认一组消息。确认发出的确切时刻取决于消息投递的模式（持久化还是临时的）和消息将如何路由的队列属性。也就是说不同的消息将在不同的时刻准备好Ack。这意味着Ack与对应的消息将以不同的顺序到达。应用应该尽可能不依赖Ack的顺序。

关键字: ack confirm nack rabbitmq reject 发布者确认 消费者应答