---

RabbitMQ的消息传递顺序是生产者===>交换机===>队列===>消费者，前文我们研究了rabbitmq的持久化机制，从一定层面上保障了rabbitmq运行时故障导致数据丢失的问题。还研究了消费者向rabbitmq应答的机制，那么生产者将消息发送给rabbitmq时，这一阶段的安全性如何保障？此处就需要引入发布确认机制，注意这里的发布确认和之前的消息应答是不一样的，可以简单理解为消息应答是消费者向rabbitmq应答，而发布确认是rabbitmq向生产者进行确认。

一、发布确认原理

生产者可以将信道设置成 confirm 模式，一旦信道进入 confirm 模式，所有在该信道上面发布的消息都将会被指派一个唯一的 ID(从 1 开始)，一旦消息被投递到所有匹配的队列之后，broker就会发送一个确认给生产者(包含消息的唯一 ID)，这就使得生产者知道消息已经正确到达目的队列了。
如果消息和队列是可持久化的，那么确认消息会在将消息写入磁盘之后发出。broker 回传给生产者的确认消息中 delivery-tag 域包含了确认消息的序列号，此外 broker 也可以设置 basic.ack 的 multiple 域，表示到这个序列号之前的所有消息都已经得到了处理。
confirm 模式最大的好处在于它是异步的，一旦发布一条消息，生产者应用程序就可以在等待信道返回确认消息的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用便可以通过回调方法来处理该确认消息，如果 RabbitMQ 因为自身内部错误导致消息丢失，就会发送一条 nack 消息给生产者，生产者应用程序同样可以在回调方法中处理该 nack 消息。

二、发布确认策略

1、开启方法

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

2、单个确认发布

这是一种简单的确认方式，它是一种同步确认发布的方式，也就是发布一个消息之后只有它被确认发布，后续的消息才能继续发布。这种确认方式有一个最大的缺点就是:发布速度特别的慢，因为如果没有确认发布的消息就会阻塞所有后续消息的发布，这种方式最多提供每秒不超过数百条发布消息的吞吐量。

private static final MESSAGE_COUNT = 1000;
public static void main(String[] args) throws Exception {
    publishMessageIndividually();
}
public static void publishMessageIndividually() throws Exception {
	Channel channel = RabbitMqUtils.getChannel();
	//随机生成一个队列名字
 	String queueName = UUID.randomUUID().toString();
	channel.queueDeclare(queueName, false, false, false, null);
	//开启发布确认 
    channel.confirmSelect();
	//记录开始时间
	long begin = System.currentTimeMillis();
	for (int i = 0; i < MESSAGE_COUNT; i++) { 
        String message = i + "";
		channel.basicPublish("", queueName, null, message.getBytes());
		//服务端返回 false 或超时时间内未返回，生产者可以消息重发 
        boolean flag = channel.waitForConfirms();
		if(flag){
			System.out.println("消息发送成功");
		}
	}
	//记录结束时间
	long end = System.currentTimeMillis();
	System.out.println("发布" + MESSAGE_COUNT + "个单独确认消息,耗时" + (end - begin) + "ms");
} 

waitForConfirms() 方法会一直阻塞当前线程，直到所有先前发布的单个确认消息都得到了确认或者发生错误。如果发生错误，则方法将抛出 IOException 异常。

3、批量确认发布

上面那种方式非常慢，与单个等待确认消息相比，先发布一批消息然后一起确认可以极大地提高吞吐量。当然这种方案仍然是同步的，也一样会阻塞消息的发布。这种方式虽然快了很多，但缺点就是：当发生故障导致发布出现问题时，不知道是哪个消息出现问题了，想定位具体是哪一条消息出现了问题非常困难，必须将整个批处理保存在内存中，以记录重要的信息而后重新发布消息。

private static final MESSAGE_COUNT = 1000;
public static void main(String[] args) throws Exception {
    //publishMessageIndividually();
    publishMessageBatch();
}
public static void publishMessageBatch() throws Exception {
	Channel channel = RabbitMqUtils.getChannel();
	//随机生成一个队列名字
	String queueName = UUID.randomUUID().toString();
	channel.queueDeclare(queueName, false, false, false, null);
	//开启发布确认 
    channel.confirmSelect();
	//批量确认消息大小 
    int batchSize = 100;
	//未确认消息个数 
    int outstandingMessageCount = 0;
	//记录开始时间
	long begin = System.currentTimeMillis();
	for (int i = 0; i < MESSAGE_COUNT; i++) { 
        String message = i + "";
		channel.basicPublish("", queueName, null, message.getBytes()); 
        outstandingMessageCount++;
		if (outstandingMessageCount == batchSize) { 
            channel.waitForConfirms(); 
            outstandingMessageCount = 0;
		}
	}
	//为了确保还有剩余没有确认消息 再次确认 
    if (outstandingMessageCount > 0) { 
        channel.waitForConfirms();
	}
	//记录结束时间
	long end = System.currentTimeMillis();
	System.out.println("发布" + MESSAGE_COUNT + "个批量确认消息,耗时" + (end - begin) + "ms");
} 

这种批量确认方式实际上还是通过channel.waitForConfirms();实现，只是代码逻辑上加了个数判断，每积累100个未确认的消息就会调用一次waitForConfirms()进行发布确认，实现批量的效果。

4、异步确认发布

异步确认虽然逻辑比上两个要复杂，但是性价比最高，无论是可靠性还是效率都没得说，它是利用回调函数来达到消息可靠性传递的，这个中间件也是通过函数回调来保证是否投递成功。下面是异步确认发布的基本流程，通过ackCallback和nackCallback两个回调函数来实现。

private static final MESSAGE_COUNT = 1000;
public static void main(String[] args) throws Exception {
    //publishMessageIndividually();
    //publishMessageBatch();
    publishMessageAsync();
}
public static void publishMessageAsync() throws Exception {
	Channel channel = RabbitMqUtils.getChannel();
	String queueName = UUID.randomUUID().toString();
	channel.queueDeclare(queueName, false, false, false, null);
	//开启发布确认
	channel.confirmSelect();
	/** 
    * 线程安全有序的一个哈希表，适用于高并发的情况
    * 1.轻松的将序号与消息进行关联
    * 2.轻松批量删除条目 只要给到序列号即可
    * 3.支持并发访问
    */
	ConcurrentSkipListMap<Long, String> outstandingConfirms = new ConcurrentSkipListMap<>();
	/** 
    * 确认收到消息的一个回调 
    * 1.消息序列号 
    * 2.true可以确认小于等于当前序列号的消息 
    * false确认当前序列号消息 
    */
	ConfirmCallback ackCallback = (sequenceNumber, multiple) -> {
        if (multiple) {
            //返回的是小于等于当前序列号的未确认消息 是一个map
            ConcurrentNavigableMap<Long, String> confirmed = outstandingConfirms.headMap(sequenceNumber, true);
            //清除该部分未确认消息
            confirmed.clear();
        }else{
            //只清除当前序列号的消息
            outstandingConfirms.remove(sequenceNumber);
        }
    };
	ConfirmCallback nackCallback = (sequenceNumber, multiple) -> {
        String message = outstandingConfirms.get(sequenceNumber);
        System.out.println("发布的消息"+message+"未被确认，序列号"+sequenceNumber);
	};
	/** 
    * 添加一个异步确认的监听器 
    * 1.确认收到消息的回调 
    * 2.未收到消息的回调 
    */
	channel.addConfirmListener(ackCallback, nackCallback);
	//记录开始时间
	long begin = System.currentTimeMillis();
	for (int i = 0; i < MESSAGE_COUNT; i++) {
        String message = "消息" + i;
        /** 
        * channel.getNextPublishSeqNo()获取下一个消息的序列号 
        * 通过序列号与消息体进行关联 
        * 全部都是未确认的消息体 
        */
        outstandingConfirms.put(channel.getNextPublishSeqNo(), message);
        channel.basicPublish("", queueName, null, message.getBytes());
    }
	//记录结束时间
	long end = System.currentTimeMillis();
	System.out.println("发布" + MESSAGE_COUNT + "个异步确认消息,耗时" + (end - begin) + "ms");
}	

5、处理异步未确认消息

最好的解决的解决方案就是把未确认的消息放到一个基于内存的能被发布线程访问的队列，比如说用ConcurrentLinkedQueue这个队列通过nack的失败回调函数，与发布线程之间进行消息的传递。例如传递给发布者是哪个消息出现了问题，需要重传等等。

6、三种发布速度对比

总结：

• 单个发布确认：同步等待确认，简单，但吞吐量非常有限。
• 批量发布确认：批量同步等待确认，简单，合理的吞吐量，但定位问题难。
• 异步发布确认：最佳性能和资源使用，在出现错误的情况下很好控制，实现起来稍困难。

public static void main(String[] args) throws Exception {
    publishMessageIndividually();
    publishMessageBatch();
    publishMessageAsync();
}

//运行结果
发布 1,000 个单独确认消息耗时 50,278 ms
发布 1,000 个批量确认消息耗时 1,045 ms
发布 1,000 个异步确认消息耗时 92 ms