本文翻译汇总自rabbitmq的官方文档。

翻译使用谷歌翻译后简单修改，部分内容读起来仍然比较晦涩，不过意思传达到了。

可靠性指南

本页介绍了如何使用AMQP和RabbitMQ的各种功能来实现可靠的传送 - 确保消息始终被传递，甚至在系统的任何部分遇到故障。

什么可以失败？

网络问题可能是最常见的失败类。网络不仅可能出现故障，防火墙可以中断空闲连接，并且不会立即检测到网络故障。

除了连接故障之外，broker和客户端应用程序可能会随时遇到硬件故障（或软件崩溃）。此外，即使客户端应用程序持续运行，逻辑错误也可能导致通道或连接错误，迫使客户端建立新的通道或连接，并从问题中恢复。

连接失败

在连接失败的情况下，客户端将需要与broker建立新的连接。以前连接中打开的任何通道都将自动关闭，这些通道也需要重新打开。

一般来说，当连接失败时，客户端将被连接引发异常（或类似的语言结构）通知。官方Java和.NET客户端还提供了回调方法，让您听到其他上下文中的连接失败 - Java在Connection和Channel类上都提供了ShutdownListener回调，.NET客户端提供了IConnection.ConnectionShutdown和IModel.ModelShutdown事件目的。

Acknowledgements和confirm

当连接失败时，消息可能在客户端和服务器之间传输 - 它们可能处于被解析或生成的中间，在OS缓冲区或电线上。传输中的消息将丢失 - 它们将需要重传。Acknowledgements让服务器和客户端知道何时这样做。

Acknowledgements可以在两个方向使用 - 允许消费者向服务器指示它已经接收/处理了消息，并允许服务器向生产者指示相同的东西。 RabbitMQ将后一种情况称为"confirm"。

当然，TCP确保已经接收到数据包，并且将重新发送，直到它们 - 但这只是网络层。Acknowledgements和confirm表明已收到消息并采取行动。confirm信号表示接收到消息，并且转让所有权，接收方承担全部责任。

Acknowledgements因此具有语义 - 消费的应用程序不应该confirm消息，直到它完成了与它们需要的任何操作 - 将它们记录在数据库中，转发它们，将它们打印到纸张或其他任何东西上。一旦这样做，broker可以自由地忘记该消息。

同样，broker一旦承担责任，就会confirm消息（见这里是什么意思）。

confirm的使用保证至少一次Delivery。没有confirm，在发布和消费操作期间可能发生消息丢失，并且只有最多的一次Delivery才能得到保证。

用心跳检测死TCP连接

在某些类型的网络故障中，数据包丢失可能意味着中断的TCP连接需要较长时间（例如，在Linux上使用默认配置约11分钟）才能被操作系统检测到。 AMQP 0-9-1提供心跳功能，以确保应用程序层及时发现连接中断（以及完全无响应的对等体）。心跳也可以防止可能终止"空闲"TCP连接的某些网络设备。有关详细信息，请参阅心跳。

在broker

为了避免在broker中丢失消息，我们需要应对broker重新启动，broker硬件故障，甚至是甚至broker崩溃。

为了确保重新启动时消息和broker定义生效，我们需要确保它们在磁盘上。 AMQP标准具有交换，队列和持久消息的耐久性概念，要求持久对象或持久消息将在重新启动后生存。有关持久性和持久性的具体标志的更多详细信息，请参见"AMQP概念指南"。

群集和高可用性

如果我们需要确保我们的broker幸存硬件故障，我们可以使用RabbitMQ的集群。在RabbitMQ集群中，所有定义（交换，绑定，用户等）都跨整个集群镜像。队列的行为方式不同，默认情况下只驻留在单个节点上，但可以跨多个或所有节点进行镜像。队列保持可见，并且可以从所有节点访问，无论它们位于何处。

镜像队列在所有已配置的集群节点之间复制其内容，可以无缝地容忍节点故障，并且不会丢失消息（尽管请参阅非同步从站上的此注释）。然而，消费应用程序需要注意，当队列失败时，消费者将被取消，他们将需要重新考虑 - 有关详细信息，请参阅文档。

在Producer

当使用confirms时，从通道恢复的生产者或连接故障应重发任何尚未从broker收到confirm的消息。这里存在消息重复的可能性，因为broker可能发送了一个从未到达生产者的confirm（由于网络故障等）。因此，消费者应用程序将需要以幂等（重复执行的效果一致）方式执行重复数据删除或处理传入的消息。

确保消息路由

在某些情况下，生产者可能很重要的是确保他们的消息被路由到队列（尽管并不总是 - 在公共子系统生产者只会发布的情况下，如果没有消费者感兴趣，那么消息是正确的丢弃）。

为了确保消息被路由到一个已知的队列，生产者只能声明一个目标队列并直接发布给它。如果消息可能以更复杂的方式进行路由，但是生产者仍然需要知道他们是否到达了至少一个队列，则可以在basic.publish上设置mandatory标志，确保basic.return（包含回复码和一些文本解释）将被发送回客户端，如果没有队列被适当地绑定。

在消费者

在网络故障（或节点崩溃）的情况下，可能消息重复，消费者必须准备好处理它们。如果可能，最简单的方法是确保您的消费者以幂等方式处理消息，而不是明确处理重复数据消除。

不能处理的消息

如果消费者确定它不能处理消息，那么它可以使用basic.reject（或basic.nack）拒绝它，要求服务器重新启动它（在这种情况下，服务器可能被配置为死信）代替。

消费者Acknowledgements和Producerconfirm

介绍

使用消息传递broker（如RabbitMQ）的系统按照定义分布。由于发送的协议方法（消息）不能保证到达对等体或被其成功处理，所以发布者和消费者都需要一种用于传送和处理confirm的机制。 RabbitMQ支持的几种消息协议提供了这样的功能。

（消费者）DeliveryAcknowledgements

当RabbitMQ向消费者发送消息时，需要知道何时成功发送消息。什么样的逻辑优化取决于系统。因此，它主要是应用程序的决定。

在我们继续讨论其他主题之前，重要的是要解释Delivery是如何被识别的（而且confirm表明他们各自的Delivery）。当消费者（订阅）注册时，消息将由RabbitMQ使用basic.deliver方法传递（推送）。该方法携带Deliverytags，其唯一地标识信道上的传递。

Deliverytags是单调增长的正整数，并由客户端库呈现。承认Delivery的客户端库方法将Deliverytags作为参数。

频道预取设置（QoS）

由于消息以异步方式发送（推送）到客户端，因此通常在任何给定时刻通常会有多个消息"在飞行中"。此外，客户端的手动confirm本质上也是异步的。所以有一个未被confirm的Deliverytags的滑动窗口。开发人员通常会倾向于限制此窗口的大小，以避免消费者端端的无限缓冲区问题。这是通过使用basic.qos方法设置"预取计数"值来完成的。该值定义了通道上允许的未confirmDelivery的最大数量。一旦数量达到配置的计数，RabbitMQ将停止在通道上传递更多消息，除非至少有一个未confirm的消息被confirm。

例如，鉴于在通道Ch上未confirm的Deliverytags5,6,7和8设置为4，RabbitMQ不会再推送任何更多的Delivery，除非至少有一个未完成的Delivery被confirm。当通过delivery_tag设置为8的confirm帧到达该通道时，RabbitMQ将会注意并传递一条消息。

值得重申的是，Delivery流程和手动客户端confirm完全是异步的。因此，如果在飞行中已经有Delivery时改变了预取值，则出现自然竞争条件，并且可能暂时超过在通道上预取计数未confirm的消息。

可以为通道或消费者配置QoS设置。有关详细信息，请参阅消费者预取。

即使在手动confirm模式下，QoS设置也不会影响使用basic.get（"pull API"）获取的消息。

Producer confirm

使用标准AMQP 0-9-1，保证消息不丢失的唯一方法是使用事务 - 使信道事务发布，发布消息，提交。在这种情况下，交易是不必要的重量级，并将吞吐量降低250倍。为了弥补这一点，引入了confirm机制。它模仿了协议中已经存在的消费者confirm机制。

要启用confirm，客户端发送confirm.select方法。根据是否设置不等待，broker可以通过confirm.select-ok进行回复。一旦在通道上使用了confirm.select方法，就被认为处于confirm模式。事务通道不能进入confirm模式，一旦通道处于confirm模式，则不能进行事务处理。

一旦一个通道处于confirm模式，broker和客户端都会计数消息（从第一个confirm.select开始计数）。然后，broker通过在同一个频道上发送basic.ack来confirm消息。发送tags字段包含已confirm消息的序列号。broker还可以在basic.ack中设置多个字段，以指示所有到达并包含具有序列号的消息的消息已被处理。

下面是Java中以confirm模式向通道发布大量消息并等待confirm的示例。

// This software, the RabbitMQ Java client library, is triple-licensed under the

// Mozilla Public License 1.1 ("MPL"), the GNU General Public License version 2

// ("GPL") and the Apache License version 2 ("ASL"). For the MPL, please see

// LICENSE-MPL-RabbitMQ. For the GPL, please see LICENSE-GPL2. For the ASL,

// please see LICENSE-APACHE2.

// This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND,

// either express or implied. See the LICENSE file for specific language governing

// rights and limitations of this software.

// If you have any questions regarding licensing, please contact us at

// info@rabbitmq.com.

package com.rabbitmq.examples;

import java.io.IOException;

import com.rabbitmq.client.Channel;

import com.rabbitmq.client.Connection;

import com.rabbitmq.client.ConnectionFactory;

import com.rabbitmq.client.MessageProperties;

import com.rabbitmq.client.QueueingConsumer;

public class ConfirmDontLoseMessages {

static int msgCount = 10000;

final static String QUEUE_NAME = "confirm-test";

static ConnectionFactory connectionFactory;

public static void main(String[] args)

throws IOException, InterruptedException

{

if (args.length > 0) {

msgCount = Integer.parseInt(args[0]);

}

connectionFactory = new ConnectionFactory();

// Consume msgCount messages.

(new Thread(new Consumer())).start();

// Publish msgCount messages and wait for confirms.

(new Thread(new Publisher())).start();

}

@SuppressWarnings("ThrowablePrintedToSystemOut")

static class Publisher implements Runnable {

public void run() {

try {

long startTime = System.currentTimeMillis();

// Setup

Connection conn = connectionFactory.newConnection();

Channel ch = conn.createChannel();

ch.queueDeclare(QUEUE_NAME, true, false, false, null);

ch.confirmSelect();

// Publish

for (long i = 0; i < msgCount; ++i) {

ch.basicPublish("", QUEUE_NAME,

MessageProperties.PERSISTENT_BASIC,

"nop".getBytes());

}

ch.waitForConfirmsOrDie();

// Cleanup

ch.queueDelete(QUEUE_NAME);

ch.close();

conn.close();

long endTime = System.currentTimeMillis();

System.out.printf("Test took %.3fs\n",

(float)(endTime - startTime)/1000);

} catch (Throwable e) {

System.out.println("foobar :(");

System.out.print(e);

}

static class Consumer implements Runnable {

public void run() {

try {

// Setup

Connection conn = connectionFactory.newConnection();

Channel ch = conn.createChannel();

ch.queueDeclare(QUEUE_NAME, true, false, false, null);

// Consume

QueueingConsumer qc = new QueueingConsumer(ch);

ch.basicConsume(QUEUE_NAME, true, qc);

for (int i = 0; i < msgCount; ++i) {

qc.nextDelivery();

}

// Cleanup

ch.close();

conn.close();

} catch (Throwable e) {

System.out.println("Whoosh!");

System.out.print(e);

}

否定confirm

在特殊情况下，当broker无法成功处理消息时，代替basic.ack，broker将发送一个basic.nack。在这种情况下，basic.nack的字段具有与basic.ack中相应的含义相同的含义，并且请求字段应该被忽略。broker表示无法处理消息，拒绝对其发送一则或多封消息;在这一点上，客户端可能会选择重新发布消息。

通道置于confirm模式后，所有后续发布的消息将被confirm或不存在一次。不能保证消息被confirm多久。没有任何消息将被confirm和否定。

如果在负责队列的Erlang进程中发生内部错误，则只会传递basic.nack。

当消息被重新排队时，如果可能，它将被置于其队列中的原始位置。如果没有（由于多个消费者共享队列时由于其他消费者的并发Delivery和confirm），该消息将被重新排列到更接近队列头的位置。

什么时候confirm message？

对于不可路由的消息，一旦交换验证消息将不会路由到任何队列（返回空列表的队列），broker将发出confirm。如果消息也被发布为强制性，则basic.return将在basic.ack之前发送给客户端。否定的confirm也是如此（basic.nack）。

对于可路由消息，当所有队列接受消息时，发送basic.ack。对于路由到持久队列的持久消息，这意味着持续到磁盘。对于镜像队列，这意味着所有镜像都已接受该消息。

持久化消息的Ack延迟

在将消息持续存储到磁盘后，将发送一个持久消息的basic.ack路由到持久化队列。 RabbitMQ消息存储在间隔（几百毫秒）之后分批地将消息存储到磁盘，以最小化fsync（2）调用的数量，或者当队列空闲时。这意味着在一个恒定的负载下，basic.ack的延迟可以达到几百毫秒。为了提高吞吐量，强烈建议应用程序异步处理confirm（作为流）或发布批次的消息，并等待未完成的confirm。客户端库之间的具体API有所不同。

Producerconfirm的订购注意事项

在大多数情况下，RabbitMQ将按照发布的相同顺序向Producerconfirm消息（这适用于在单个频道上发布的消息）。然而，发布者的confirm是异步发出的，可以confirm一个消息或一组消息。发出confirm的确切时刻取决于消息的传递模式（持久与瞬态）以及消息被路由到的队列的属性（见上文）。也就是说，不同的消息可以被认为是准备好在不同的时间进行confirm。这意味着与其各自的消息相比，confirm可以以不同的顺序到达。应用程序不应该依赖于confirm的顺序。

Producer confirm和保证Delivery

如果在所有消息写入磁盘之前崩溃，broker将丢失持久的消息。在某些情况下，这将导致broker以惊人的方式表现。

例如，考虑这种情况：

客户端向持久队列发布持久消息

客户端从队列中消耗消息（指出消息是持久的，队列持久的），但是还没有确定，

broker死亡并重新启动，

客户端重新连接并开始消费消息。

在这一点上，客户端可以合理地假设该消息将被再次发送。不是这样：重新启动导致broker丢失该消息。为了保证持久性，客户应该使用confirm。如果Producer的频道处于confirm模式，Producer将不会收到丢失的消息的confirm（因为该消息尚未写入磁盘）。

限制

最大Deliverytags

Deliverytags是一个64位长的值，因此其最大值为9223372036854775807.由于每个渠道的Deliverytags是范围限定的，所以Producer或消费者在实践中不太可能超过此值。

个人理解：

上面的描述非常复杂，我总结来说，有一下几种情况需要在开发中注意：

Producter发送消息之后，没有收到Broker的confirm：

消息可能终止在了传送的层面，如操作系统缓冲层，或者网络传输层，或者是在Broker接受之后，由于内部故障不能处理，如exchang故障，也不会发送confirm给Producter。所以，在我们的系统中，我们在producter端其实是有数据库表存储需要发送的消息的，我们一次批量发送100条消息，一旦收到confirm，就会删除这部分消息，所以没有接收到confirm的话，就不删除相应的数据。

还要保证消息的幂等。如此就可以保证在producter层面不会丢失消息。

broker接收到消息之后，在exchang或者queue中丢失：

设置消息和exchang和queue都为持久的。

找不到消息对应的queue

我们的程序不会出现这种情况。

queue没有对应的consumer

这种情况下，消息会在queue中挤压，也不会丢失。

消息可能会重复发送，所以需要保证消息处理的幂等性。

broker将在下面的情况中对消息进行confirm：

broker发现当前消息无法被路由到指定的queues中（如果设置了mandatory属性，则broker会发送basic.return）
非持久属性的消息到达了其所应该到达的所有queue中（和镜像queue中）
持久消息到达了其所应该到达的所有queue中（和镜像中），并被持久化到了磁盘（fsync）
持久消息从其所在的所有queue中被consume了（如果必要则会被ack）

批量发送消息，并批量接收确认的例子：

// 发送持久化消息，消息内容为helloWorld
; i < msgCount; ++i)

{

ch.basicPublish("", QUEUE_NAME, MessageProperties.PERSISTENT_BASIC, "helloWorld".getBytes());

}

// 等待所有消息都被ack或者nack，如果某个消息被nack，则抛出IOException