RabbitMQ 学习（四）-- Publisher Confirms（发布确认模式）

发布确认模式：RabbitMQ tutorial - Reliable Publishing with Publisher Confirms — RabbitMQ

1、发布确认原理

生产者将信道设置成 confirm 模式，一旦信道进入 confirm 模式，所有在该信道上面发布的消息都将会被指派一个唯一的ID(从1开始)，一旦消息被投递到所有匹配的队列之后，broker 就会发送一个确认给生产者(包含消息的唯一ID)，这就使得生产者知道消息已经正确到达目的队列了，如果消息和队列是可持久化的，那么确认消息会在将消息写入磁盘之后发出，broker回传给生产者的确认消息中 delivery-tag 域包含了确认消息的序列号，此外 broker 也可以设置 basic.ack 的multiple 域，表示到这个序列号之前的所有消息都已经得到了处理。

confirm 模式最大的好处在于他是异步的，一旦发布一条消息，生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用便可以通过回调方法来处理该确认消息，如果 RabbitMQ 因为自身内部错误导致消息丢失，就会发送一条 nack 消息，生产者应用程序同样可以在回调方法中处理该 nack 消息。

2、发布确认的策略

发布确认默认是没有开启的，如果要开启需要调用方法 confirmSelect()，每当你要想使用发布确认，都需要在channel 上调用该方法

Channel channel = connection.createChannel();
channel.confirmSelect();

1）单个发布确认

这是一种简单的确认方式，它是一种同步确认发布的方式，也就是发布一个消息之后只有它被确认发布，后续的消息才能继续发布waitForConfirmsOrDie(long)这个方法只有在消息被确认的时候才返回，如果在指定时间范围内这个消息没有被确认那么它将抛出异常。

这种确认方式有一个最大的缺点就是: 发布速度特别的慢，因为如果没有确认发布的消息就会阻塞所有后续消息的发布，这种方式最多提供每秒不超过数百条发布消息的吞吐量。当然对于某些应用程序来说这可能已经足够了。

public static void publicMessageIndividually() throws IOException, TimeoutException, InterruptedException {
    Channel channel = RabbitMQUtil.getChannel();
    // 声明队列
    String queueName = UUID.randomUUID().toString();
    channel.queueDeclare(queueName, true, false, false, null);
    // 开启发布确认
    channel.confirmSelect();
    long start = System.currentTimeMillis();
    // 批量发消息
    for (int i = 0; i < MESSAGE_NUM; i++) {
        String msg = "消息"+i;
        channel.basicPublish("", queueName, null, msg.getBytes());
        // 单个消息发布确认
        boolean flag = channel.waitForConfirms();
        //            if (flag){
        //                System.out.println("====消息发布成功====");
        //            }
    }
    long end = System.currentTimeMillis();
    System.out.println("发布 "+ MESSAGE_NUM +"个单个发布消息确认耗时：" + (end-start) + "ms");
}

2）批量发布确认

上面那种方式非常慢，与单个等待确认消息相比，先发布一批消息然后一起确认可以极大地提高吞吐量。这种方案仍然是同步的，也一样阻塞消息的发布。

缺点: 当发生故障导致发布出现问题时，不知道是哪个消息出现问题了，我们必须将整个批处理保存在内存中，以记录重要的信息而后重新发布消息。

public static void publicMessageBatch() throws IOException, TimeoutException, InterruptedException {
    Channel channel = RabbitMQUtil.getChannel();
    // 声明队列
    String queueName = UUID.randomUUID().toString();
    channel.queueDeclare(queueName, true, false, false, null);
    // 开启发布确认
    channel.confirmSelect();
    long start = System.currentTimeMillis();
    // 批量发布确认的大小
    int batchSize = 100;
    // 批量发消息
    for (int i = 0; i < MESSAGE_NUM; i++) {
        String msg = "消息"+i;
        channel.basicPublish("", queueName, null, msg.getBytes());
        // 量消息发布确认 判断达到 100 条后 批量确认一次
        //            if (i % batchSize == 0){
        //                System.out.println("====消息发布成功====");
        //            }
    }
    long end = System.currentTimeMillis();
    System.out.println("发布 "+ MESSAGE_NUM +"个批量发布消息确认耗时：" + (end-start) + "ms");
}

3）异步发布确认

异步确认虽然编程逻辑比上两个要复杂，但是性价比最高，无论是可靠性还是效率都没得说，他是利用回调函数来达到消息可靠性传递的，这个中间件也是通过函数回调来保证是否投递成功，下面就让我们来详细讲解异步确认是怎么实现的。

public static void publicMessageAsync() throws IOException, TimeoutException, InterruptedException {
    Channel channel = RabbitMQUtil.getChannel();
    // 声明队列
    String queueName = UUID.randomUUID().toString();
    channel.queueDeclare(queueName, true, false, false, null);
    // 开启发布确认
    channel.confirmSelect();
    long start = System.currentTimeMillis();
    // 消息确认成功 回调函数 参数1：消息的标记 参数2：是否为批量
    ConfirmCallback ackCallback = (deliveryTag, multiple)->{
        // System.out.println("确认发布的消息：" + deliveryTag);
    };
    // 消息确认失败 回调函数
    ConfirmCallback nackCallback = (deliveryTag, multiple)->{
        // System.out.println("未确认发布的消息：" + deliveryTag);
    };
    // 准备消息监听器，监听那些消息成功了，那些消息失败了
    channel.addConfirmListener(ackCallback, nackCallback);
    // 批量发消息
    for (int i = 0; i < MESSAGE_NUM; i++) {
        String msg = "消息"+i;
        channel.basicPublish("", queueName, null, msg.getBytes());
    }
    long end = System.currentTimeMillis();
    System.out.println("发布 "+ MESSAGE_NUM +"个异步发布消息确认耗时：" + (end-start) + "ms");
}

如何处理异步未确认的消息：

其实监听器是从一开始就工作的，但是监听器监听的速度没有生产者发送消息的速度快，当监听器监听到100多的时候生产者的1000条就已经发完。（消息都发送完了，监听的结果还没完全返回。）

最好的解决的解决方案就是把未确认的消息放到一个基于内存的能被发布线程访问的队列，比如说用 ConcurrentLinkedQueue 这个队列在 confirm callbacks 与 发布线程 之间进行消息的传递。

ackCallback 只会告诉你是发送失败的编号,不能给你发送失败的数据。所以只能把所有数据都存一边,删除发送成功的数据,这样剩下的都是发送失败的数据。

public static void publicMessageAsync() throws IOException, TimeoutException, InterruptedException {
    Channel channel = RabbitMQUtil.getChannel();
    // 声明队列
    String queueName = UUID.randomUUID().toString();
    channel.queueDeclare(queueName, true, false, false, null);
    // 开启发布确认
    channel.confirmSelect();

    // 记录全部消息 线程安全，适用于高并发的队列
    ConcurrentSkipListMap<Long, String> outStandingConfirm = new ConcurrentSkipListMap<>();

    long start = System.currentTimeMillis();

    // 消息确认成功 回调函数 参数1：消息的标记 参数2：是否为批量
    ConfirmCallback ackCallback = (deliveryTag, multiple)->{
        // System.out.println("确认发布的消息：" + deliveryTag);
        // 2、删除掉已经确认的消息，剩下的就是未发送的消息 一般不是使用批量确认
        if (multiple){
            ConcurrentNavigableMap<Long, String> confirms = outStandingConfirm.headMap(deliveryTag);
            confirms.clear();
        }else {
            outStandingConfirm.remove(deliveryTag);
        }
    };
    // 消息确认失败 回调函数
    ConfirmCallback nackCallback = (deliveryTag, multiple)->{
        // System.out.println("未确认发布的消息：" + deliveryTag);
        // 3、打印未发送的消息有哪些
    };
    // 准备消息监听器，监听那些消息成功了，那些消息失败了
    channel.addConfirmListener(ackCallback, nackCallback);
    // 批量发消息
    for (int i = 0; i < MESSAGE_NUM; i++) {
        String msg = "消息"+i;
        channel.basicPublish("", queueName, null, msg.getBytes());
        // 1、此处记录所有要发送的消息
        // System.out.println("channel.getNextPublishSeqNo(): " + channel.getNextPublishSeqNo());
        outStandingConfirm.put(channel.getNextPublishSeqNo()-1, msg);
    }
    long end = System.currentTimeMillis();
    System.out.println("发布 "+ MESSAGE_NUM +"个异步发布消息确认耗时：" + (end-start) + "ms");
}

4）对比

// 发布消息的数量
private static final int MESSAGE_NUM = 1000;

public static void main(String[] args) throws IOException, InterruptedException, TimeoutException {
    // 1、单个发布确认
    publicMessageIndividually();    	// 发布 1000个单个发布消息确认耗时：629ms
    // 2、批量发布确认
    publicMessageBatch();            	// 发布 1000个批量发布消息确认耗时：85ms
    // 3、异步批量确认
    publicMessageAsync();               // 发布 1000个异步发布消息确认耗时：62ms
}