from http://m.oschina.net/blog/142095
Confirms (aka Publisher Acknowledgements)
Using standard AMQP, the only way to guarantee that a message isn't lost is by using transactions -- make the channel transactional, publish the message, commit. In this case, transactions are unnecessarily heavyweight and decrease throughput by a factor of 250. To remedy this, a confirmation mechanism was introduced.
如果采用标准的 AMQP 协议，则唯一能够保证消息不会丢失的方式是利用事务机制 -- 令 channel 处于 transactional 模式、向其 publish 消息、执行 commit 动作。在这种方式下，事务机制会带来大量的多余开销，并会导致吞吐量下降 250% 。为了补救事务带来的问题，引入了 confirmation 机制（即 Publisher Confirm）。
To enable confirms, a client sends the confirm.select method. Depending on whether no-wait was set or not, the broker may respond with a confirm.select-ok. Once the confirm.select method is used on a channel, it is said to be in confirm mode. A transactional channel cannot be put into confirm mode and once a channel is in confirm mode, it cannot be made transactional.
为了使能 confirm 机制，client 首先要发送 confirm.select 方法帧。取决于是否设置了 no-wait 属性，broker 会相应的判定是否以 confirm.select-ok 进行应答。一旦在 channel 上使用 confirm.select 方法，channel 就将处于 confirm 模式。处于 transactional 模式的 channel 不能再被设置成 confirm 模式，反之亦然。
Once a channel is in confirm mode, both the broker and the client count messages (counting starts at 1 on the first confirm.select). The broker then confirms messages as it handles them by sending a basic.ack on the same channel. The delivery-tag field contains the sequence number of the confirmed message. The broker may also set the multiple field in basic.ack to indicate that all messages up to and including the one with the sequence number have been handled.
一旦 channel 处于 confirm 模式，broker 和 client （译者注：client 的计数自行实现）都将启动消息计数（以 confirm.select 为基础从 1 开始计数）。broker 会在处理完消息后（译者注：这里的说法会让人产生错误理解，何为处理完消息？后续还有涉及），在当前 channel 上通过发送 basic.ack 的方式对其（消息）进行 confirm 。delivery-tag 域的值标识了被 confirm 消息的序列号。broker 也可以通过设置 basic.ack 中的 multiple 域来表明到指定序列号为止的所有消息都已被 broker 正确的处理了。
An example in Java that publishes a large number of messages to a channel in confirm mode and waits for the acknowledgements can be found here.
一个 Java 示例展现了 publish 大量消息到一个处于 confirm 模式的 channel 并等待获取 acknowledgement 的情况，示例在这里。
Negative Acknowledgment
In exceptional cases when the broker is unable to handle messages successfully, instead of a basic.ack, the broker will send a basic.nack. In this context, fields of the basic.nack have the same meaning as the corresponding ones in basic.ack and the requeue field should be ignored. By nack'ing one or more messages, the broker indicates that it was unable to process the messages and refuses responsibility for them; at that point, the client may choose to re-publish the messages.在异常情况发生时，broker 将无法成功处理相应的消息，此时 broker 将发送 basic.nack 来代替 basic.ack 。在这个情形下，basic.nack 中各域值的含义与 basic.ack 中相应各域含义是相同的，同时 requeue域的值应该被忽略。 通过 nack 一条或多条消息 ， broker 表明自身无法对相应消息完成处理，并拒绝为这些消息的处理负责。在这种情况下，client 可以选择将消息 re-publish 。
After a channel is put into confirm mode, all subsequently published messages will be confirmed or nack'd once. No guarantees are made as to how soon a message is confirmed. No message will be both confirmed and nack'd.
在 channel 被设置成 confirm 模式之后，所有被 publish 的后续消息都将被 confirm（即 ack） 或者被 nack 一次。但是没有对消息被 confirm 的快慢做任何保证，并且同一条消息不会既被 confirm 又被 nack 。
basic.nack will only be delivered if an internal error occurs in the Erlang process responsible for a queue.
basic.nack 只会在负责 queue 功能的 Erlang 进程发生内部错误时被发送。
When will messages be confirmed?
消息会在何时被 confirm？
The broker will confirm messages once:
broker 将在下面的情况中对消息进行 confirm ：
it decides a message will not be routed to queues
(if the mandatory flag is set then the basic.return is sent first)or
broker 发现当前消息无法被路由到指定的 queues 中（如果设置了mandatory 属性，则 broker 会先发送basic.return）a transient message has reached all its queues (and mirrors)or
非持久属性的消息到达了其所应该到达的所有 queue 中（和镜像 queue 中）a persistent message has reached all its queues (and mirrors) and been persisted to disk (and fsynced)or
持久消息到达了其所应该到达的所有 queue 中（和镜像 queue 中），并被持久化到了磁盘（被 fsync）a persistent message has been consumed (and if necessary acknowledged) from all its queues
持久消息从其所在的所有 queue 中被 consume 了（如果必要则会被 acknowledge）
（updated in 2015-03-02）
For unroutable messages, the broker will issue a confirm once the exchange verifies a message won't route to any queue (returns an empty list of queues). If the message is also published as mandatory, the basic.return is sent to the client before basic.ack.
对于无法路由的消息，broker 会在确认了通过 exchange 无法将消息路由到任何 queue 后，发送回客户端 basic.ack 进行确认（其中包含空的 queue 列表）。如果客户端发送消息时使用了 mandatory 属性，则会发送回客户端 basic.return + basic.ack 信息。
For routable messages, the basic.ack is sent when a message has been accepted by all the queues. For persistent messages routed to durable queues, this means persisting to disk. For mirrored queues, this means that all mirrors have accepted the message.
对于能够进行路由的消息，broker 会在消息被所有 queue “接受”后，发送回客户端 basic.ack 进行确认。对于具有 persistent 属性且路由到 durable queue 的消息而言，意味着持久化到硬盘动作的完成。对于镜像队列而言，意味着所有镜像队列都“接受”了该消息之后。
Ack Latency for Persistent Messages
basic.ack for a persistent message routed to a durable queue will be sent after persisting the message to disk. The RabbitMQ message store persists messages to disk in batches after an interval (a few hundred milliseconds) to minimise the number of fsync(2) calls, or when a queue is idle. This means that under a constant load, latency for basic.ack can reach a few hundred milliseconds. To improve throughput, applications are strongly advised to process acknowledgements asynchronously (as a stream) or publish batches of messages and wait for outstanding confirms. The exact API for this varies between client libraries.
Confirms and Guaranteed Delivery
The broker loses persistent messages if it crashes before said messages are written to disk. Under certain conditions, this causes the broker to behave in surprising ways.
broker 会丢失持久化消息，如果 broker 在将上述消息写入磁盘前异常。在一定条件下，这种情况会导致 broker 以一种奇怪的方式运行。
For instance, consider this scenario:
例如，考虑下述情景：
- a client publishes a persistent message to a durable queue
一个 client 将持久消息 publish 到持久 queue 中 - a client consumes the message from the queue (noting that the message is persistent and the queue durable), but doesn't yet ack it,
另一个 client 从 queue 中 consume 消息（注意：该消息具有持久属性，并且 queue 是持久化的），当尚未对其进行 ack - the broker dies and is restarted, and
broker 异常重启 - the client reconnects and starts consuming messages.
client 重连并开始 consume 消息
At this point, the client could reasonably assume that the message will be delivered again. This is not the case: the restart has caused the broker to lose the message. In order to guarantee persistence, a client should use confirms. If the publisher's channel had been in confirm mode, the publisher would not have received an ack for the lost message (since the
在上述情景下，client 有理由认为消息需要被（broker）重新 deliver 。但这并非事实：重启（有可能）会令 broker 丢失消息。为了确保持久性，client 应该使用 confirm 机制。如果 publisher 使用的 channel 被设置为 confirm 模式，publisher 将不会收到已丢失消息的 ack（这是因为 consumer 没有对消息进行 ack ，同时该消息尚未被写入磁盘）。