RabbitMQ--持久化、事务机制、confirm机制

持久化

交换器的持久化是通过在声明队列是将 durab1e参数置为tue实现的,如果交换器不设置持久化,那么在 RabbitMQ服务重启之后,相关的交换器元数据会丢失,不过消息不会丢失,只是不能将消息发送到这个交换器中了。对一个长期使用的交换器来说,建议将其置为持久化的。

队列的持久化是通过在声明队列时将 durable参数置为true实现的。如果队列不设置持久化,那么在 RabbitMQ服务重启之后,相关队列的元数据会丢失,此时数据也会丢失。正所谓“皮之不存,毛将焉附”,队列都没有了,消息又能存在哪里呢?

队列的持久化能保证其本身的元数据不会因异常情况而丢失，但是并不能保证内部所存储的消息不会丢失。要确保消息不会丢失，需要将其设置为持久化。通过将消息的投递模式(BasicProperties中的deliveryMode属性)设置为2即可实现消息的持久化。前面示例中多次提及的MessageProperties.PERSISTENT_TEX _PLAIN 实际上是封装了这个属性:

public static final BasicProperties PERSISTENT_TXT_PLAIN = new BasicPropereties(
	null,
	null,
	2,
	0, null, null, null,
	null, null, null, null,
	null, null);

• 设置了队列和消息的持久化，当RabbitMQ 服务重启之后，消息依旧存在。
• 单单只设置队列持久化，重启之后消息会丢失;
• 单单只设置消息的持久化，重启之后队列消失，继而消息也丢失。
• 单单设置消息持久化而不设置队列的持久化显得毫无意义。

注意：可以将所有的消息都设置为持久化，但是这样会严重影响RabbitMQ的性能(随机)。写入磁盘的速度比写入内存的速度慢得不只一点点。对于可靠性不是那么高的消息可以不采用持久化处理以提高整体的吞吐量。在选择是否要将消息持久化时，需要在可靠性和吐吞量之间做一个权衡。

将交换器、队列、消息都设置了持久化之后就能百分之百保证数据不丢失了吗?答案是否定的。

首先从消费者来说，如果在订阅消费队列时将autoAck参数设置为true,那么当消费者接收到相关消息之后，还没来得及处理就宕机了，这样也算数据丢失。这种情况很好解决，将autoAck参数设置为false,并进行手动确认。

其次，在持久化的消息正确存入RabbitMQ之后，还需要有一段时间(虽然很短，但是不可忽视)才能存入磁盘之中。RabbitMQ并不会为每条消息都进行同步存盘(调用内核的fsync’方法)的处理，可能仅仅保存到操作系统缓存之中而不是物理磁盘之中。如果在这段时间内RabbitMQ服务节点发生了宕机、重启等异常情况，消息保存还没来得及落盘，那么这些消息将会丢失。

这个问题怎么解决呢?这里可以引入RabbitMQ的镜像队列机制，相当于配置了副本，如果主节点(master) 在此特殊时间内挂掉，可以自动切换到从节点(slave),这样有效地保证了高可用性，除非整个集群都挂掉。虽然这样也不能完全保证RabbitMQ消息不丢失，但是配置了镜像队列要比没有配置镜像队列的可靠性要高很多，在实际生产环境中的关键业务队列一般都会设置镜像队列。

还可以在发送端引入事务机制或者发送方确认机制来保证消息已经正确地发送并存储至RabbitMQ中，前提还要保证在调用channel. basicPublish方法的时候交换器能够将消息正确路由到相应的队列之中。

生产者确认

在使用RabbitMQ的时候，可以通过消息持久化操作来解决因为服务器的异常崩溃而导致的消息丢失，除此之外，我们还会遇到一个问题，当消息的生产者将消息发送出去之后，消息到底有没有正确地到达服务器呢?如果不进行特殊配置，默认情况下发送消息的操作是不会返回任何信息给生产者的，也就是默认情况下生产者是不知道消息有没有正确地到达服务器。如果在消息到达服务器之前已经丢失，持久化操作也解决不了这个问题，因为消息根本没有到达服务器，何谈持久化?

RabbitMQ针对这个问题，提供了两种解决方式：

1. 通过事务机制实现
2. 通过发送方确认（publisher confirm）机制实现

事务机制：
RabbitMQ客户端中与事务机制相关的方法有三个: channel. txSelect、channel. txCommit和channel. txRollback。

• channel.txSelect用于将当前的信道设置成事务模式
• channel.txCommit用于提交事务
• channel.txRollback用于事务回滚。

在通过channel. txSelect方法开启事务之后，我们便可以发布消息给RabbitMQ了，如果事务提交成功，则消息一定到达了RabbitMQ中，如果在事务提交执行之前由RabbitMQ异常崩溃或者其他原因抛出异常，这个时候我们便可以将其捕获，进而通过执行channel. txRollback方法来实现事务回滚。注意这里的RabbitMQ中的事务机制与大多数数据库中的事务概念并不相同，需要注意区分。

channel.txSelect();
channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY,
        MessageProperties.PERSISTENT_TEXT_PLAIN,
        "transaction messages".getBytes());
channel.txCommit();

可以发现开启事务机制与不开启相比多了四个步骤：

• 客户端发送Tx.Select，将信道置为事务模式;
• Broker 回复Tx.Select-Ok，确认已将信道置为事务模式;
• 在发送完消息之后，客户端发送Tx.Commit提交事务;
• Broker 回复Tx.Commit-Ok，确认事务提交。

上述是正常情况的事务机制运转过程，如下为事务回滚：

//回滚事务
try {
    channel.txSelect();
    channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY,
            MessageProperties.PERSISTENT_TEXT_PLAIN, "tx rollbask".getBytes());
    int result = 1 / 0;
    channel.txCommit();
} catch (IOException e) {
    e.printStackTrace();
    channel.txRollback();//回滚
}

如果要发送多条消息，则将channel.basicPublish和channel.txCommit等方法包裹进循环内即可：

//发送多条消息
channel.txSelect();
for (int i = 0; i < 10; i++) {
    try {
        channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, null,
                ("message" + i).getBytes());
        channel.txCommit();
    } catch (IOException e) {
        e.printStackTrace();
        channel.txRollback();
    }
}

事务确实能够解决消息发送方和RabbitMQ 之间消息确认的问题，只有消息成功被RabbitMQ接收，事务才能提交成功，否则便可在捕获异常之后进行事务回滚，与此同时可以进行消息重发。但是使用事务机制会“吸干”RabbitMQ的性能，那么有没有更好的方法既能保证消息发送方确认消息已经正确送达，又能基本上不带来性能上的损失呢?从AMQP协议层面来看并没有更好的办法，但是RabbitMQ提供了一个改进方案，即发送方确认机制,详情请看下一节的介绍。

发送方确认机制：

生产者将信道设置成confirm(确认)模式，一旦信道进入confirm模式，所有在该信道上面发布的消息都会被指派一个唯一的ID(从1开始),一旦消息被投递到所有匹配的队列之后，RabbitMQ就会发送一个确认(Basic.Ack) 给生产者(包含消息的唯一ID),这就使得生产者知晓消息已经正确到达了目的地了。如果消息和队列是可持久化的，那么确认消息会在消息写入磁盘之后发出。

RabbitMQ回传给生产者的确认消息中的deliveryTag 包含了确认消息的序号，此外RabbitMQ也可以设置channel .basicAck方法中的multiple参数，表示到这个序号之前的所有消息都已经得到了处理，可以参考下图。注意辨别这里的确认和消费时候的确认之间的异同。

事务机制在一条消息发送之后会使发送端阻塞，以等待RabbitMQ 的回应，之后才能继续发送下一条消息。相比之下，发送方确认机制最大的好处在于它是异步的，一旦发布一条消息，生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用程序便可以通过回调方法来处理该确认消息，如果RabbitMQ因为自身内部错误导致消息丢失，就会发送一条nack (Basic.Nack) 命令，生产者应用程序同样可以在回调方法中处理该nack命令。

生产者通过调用channel. confirmSelect方法( 即Confirm.Select命令)将信道设置为confirm模式，之后RabbitMQ会返回Confirm.Select-Ok命令表示同意生产者将当前信道设置为confirm模式。所有被发送的后续消息都被ack或者nack一次，不会出现一条消息既被ack又被nack的情况，并且RabbitMQ也并没有对消息被confirm的快慢做任何保证。

//发送方确认机制
channel.confirmSelect();//将信道设置为publisher confirm模式
//之后正常发送消息
try {
    channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, null,
            "publisher confirm test".getBytes());
    if (!channel.waitForConfirms()) {
        System.out.println("send message failed");
        //都something else...
    }
} catch (InterruptedException e) {
    e.printStackTrace();
}

如果发送多条消息，只需要将channel. basicPublish和channel.waitForConfirms方法包裹在循环里面即可，可以参考事务机制，不过不需要把channel. confi rmSelect方法包裹在循环内部。

在publisher confirm模式下发送多条消息的AMQP协议流转过程可以参考下图：

对于channel.waiForConfirms而言，在RabbitMQ客户端中它有4个同类的方法：

(1) boolean waitForConfirms() throws InterruptedException;

(2) boolean waitForConfirms(long timeout) throws InterruptedException, TimeoutException;

(3) void waitForConfirmsOrDie() throws IOException, InterruptedException;

(4) void waitForConfirmsOrDie(long timeout) throws IOException, InterruptedException, TimeoutException;

如果信道没有开启publisher confirm模式，则调用任何wai tForConfirms方法都会报出java.lang.IllegalStateException。

对于没有参数的waitForConfirms方法来说，其返回的条件是客户端收到了相应的Basic. Ack/ . Nack或者被中断。

参数timeout表示超时时间，一旦等待RabbitMQ 回应超时就会抛出java.util. concurrent .TimeoutException的异常。

两个waitForConfirmsOrDie方法在接收到RabbitMQ返回的Basic.Nack之后会抛出java. io. IOException。业务代码可以根据自身的特性灵活地运用这四种方法来保障消息的可靠发送。

注意：

(1)事务机制和publisher confirm机制两者是互斥的，不能共存。如果企图将已开启事务模式的信道再设置为publisher confirm 模式，RabbitMQ 会报错: {amqp_ error, precondition_failed，"cannot switch from tx to confirm mode", 'confirm.select'}; 或者如果企图将已开启publisher confirm 模式的信道再设置为事务模式，RabbitMQ 也会报错:{amqp_ error, precondition_ failed, "cannot switch from confirm to txmode",' tx.select ' } 。

(2)事务机制和publisherconfirm机制确保的是消息能够正确地发送至RabbitMQ，这里的“发送至RabbitMQ”的含义是指消息被正确地发往至RabbitMQ的交换器，如果此交换器没有匹配的队列，那么消息也会丢失。所以在使用这两种机制的时候要确保所涉及的交换器能够有匹配的队列。更进一步地讲，发送方要配合mandatory参数或者备份交换器一起使用来提高消息传输的可靠性。

publisher confirm的优势在于并不一定需要同步确认。这里我们改进了一下使用方式，总结有如下两种:

1. 批量confirm方法:每发送一批消息后，调用channel . waitForConfirms方法，等待服务器的确认返回。
2. 异步confirm方法:提供一个回调方法，服务端确认了一条或者多条消息后客户端会回调这个方法进行处理。

在批量confirm方法中，客户端程序需要定期或者定量(达到多少条)，亦或者两者结合起来调用channel. waitForConfirms来等待RabbitMQ的确认返回。相比于前面示例中的普通confirm方法，批量极大地提升了confirm 的效率，但是问题在于出现返回Basic.Nack或者超时情况时，客户端需要将这一批次的消息全部重发，这会带来明显的重复消息数量，并且当消息经常丢失时，批量confirm的性能应该是不升反降的。

int BATCH_COUNT = 10;
//批量confirm
try {
    channel.confirmSelect();
    int MsgCount = 0;
    while (true) {
        channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, null,
                "batch confirm test".getBytes());
        //将发送出去的消息存储缓存中，缓存可以是一个ArrayList或则BlockingQueue之类的
        if (++MsgCount >= BATCH_COUNT) {
            MsgCount = 0;
            try {
                if (channel.waitForConfirms()) {
                    //将缓存中的消息清空
                }
                //将缓存中的消息重新发送
            } catch (InterruptedException e) {
                e.printStackTrace();
                //将缓存中的消息重新发送
            }
        }
    }
} catch (IOException e) {
    e.printStackTrace();
}

异步 confirm 方法的编程实现最为复杂。在客户端Channel接口中提供的addConfirmListener 方法可以添加ConfirmListener这个回调接口，这个ConfirmListener接口包含两个方法: handleAck 和handleNack， 分别用来处理RabbitMQ回传的Basic.Ack 和Basic.Nack。 在这两个方法中都包含有一个参数deliveryTag (在publisher confirm 模式下用来标记消息的唯一有序序号)。 我们需要为每一个信道维护一个“unconfirm”的消息序号集合，每发送一条消息， 集合中的元素加1。

每当调用ConfirmListener 中的handleAck方法时，“unconfirm”集合中删掉相应的一条(multiple设置为false)或者多条(multiple 设置为true)记录。从程序运行效率.上来看，这个“unconfirm”集合最好采用有序集合SortedSet的存储结构。事实上，Java 客户端SDK中的waitForConfirms方法也是通过SortedSet维护消息序号的。下列代码为我们演示了异步confirm的编码实现，其中的confirmSet就是一个SortedSet类型的集合。

SortedSet<Long> confirmSet = new TreeSet<>();
//异步confirm
channel.confirmSelect();
channel.addConfirmListener(new ConfirmListener() {
    @Override
    public void handleAck(long deliveryTag, boolean multiple) throws IOException {
        if (multiple) {
            confirmSet.headSet(deliveryTag - 1).clear();
        } else {
            confirmSet.remove(deliveryTag);
        }
    }

    @Override
    public void handleNack(long deliveryTag, boolean multiple) throws IOException {
        System.out.println("Nack, SeqNo: " + deliveryTag + ", multiple: " + multiple);
        if (multiple) {
            confirmSet.headSet(deliveryTag - 1).clear();
        } else {
            confirmSet.remove(deliveryTag);
        }
        //这里添加处理消息重复的场景
    }
});
//下面演示一直发送消息的场景
while (true) {
    long nextSeqNo = channel.getNextPublishSeqNo();
    channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, MessageProperties.PERSISTENT_TEXT_PLAIN,
            "sending".getBytes());
    confirmSet.add(nextSeqNo);
}

最后我们将事务、普通confirm、批量confirm和异步confirm这4种方式放到一起来比较下彼此的QPS。

可以看到批量confirm和异步confirm这两种方式所呈现的性能要比其余两种好得多。事务机制和普通confirm 的方式吐吞量很低，但是编程方式简单，不需要在客户端维护状态(这里指的是维护deliveryTag及缓存未确认的消息)。批量confirm方式的问题在于遇到RabbitMQ服务端返回Basic. Nack需要重发批量消息而导致的性能降低。异步confirm方式编程模型最为复杂，而且和批量confirm 方式一样需要在客户端维护状态。在实际生产环境中采用何种方式，这里就仁者见仁智者见智了，不过强烈建议使用异步confirm的方式。