RabbitMQ高级

一、消息可靠性

你用支付宝给商家支付，如果是个仔细的人，会考虑我转账的话，会不会把我的钱扣了，商家没有收到我的钱？

一般我们使用支付宝或微信转账支付的时候，都是扫码，支付，然后立刻得到结果，说你支付了多少钱，如果你绑定的是银行卡，可能这个时候你并没有收到支付的确认消息。往往是在一段时间之后，你会收到银行卡发来的短信，告诉你支付的信息。

支付平台如何保证这笔帐不出问题？

支付平台必须保证数据正确性，保证数据并发安全性，保证数据最终一致性。
支付平台通过如下几种方式保证数据一致性：

1、分布式锁
这个比较容易理解，就是在操作某条数据时先锁定，可以用redis或zookeeper等常用框架来实现。 比如我们在修改账单时，先锁定该账单，如果该账单有并发操作，后面的操作只能等待上一个操作的锁释放后再依次执行。

优点：能够保证数据强一致性。 缺点：高并发场景下可能有性能问题。

2、消息队列
消息队列是为了保证最终一致性，我们需要确保消息队列有ack机制 客户端收到消息并消费处理完成后，客户端发送ack消息给消息中间件，如果消息中间件超过指定时间还没收到ack消息，则定时去重发消息。比如我们在用户充值完成后，会发送充值消息给账户系统，账户系统再去更改账户余额。

优点：异步、高并发 缺点：有一定延时、数据弱一致性，并且必须能够确保该业务操作肯定能够成功完成，不可能失败。

我们可以从以下几方面来保证消息的可靠性

1. 客户端代码中的异常捕获，包括生产者和消费者
2. AMQP/RabbitMQ的事务机制
3. 发送端确认机制
4. 消息持久化机制
5. Broker端的高可用集群
6. 消费者确认机制
7. 消费端限流
8. 消息幂等性

异常捕获机制

先执行行业务操作，业务操作成功后执行行消息发送，消息发送过程通过try catch 方式捕获异常，在异常处理理的代码块中执行行回滚业务操作或者执行行重发操作等。这是一种最大努力确保的方式，并无法保证100%绝对可靠，因为这里没有异常并不代表消息就一定投递成功。

另外，可以通过spring.rabbitmq.template.retry.enabled=true 配置开启发送端的重试

AMQP/RabbitMQ的事务机制

没有捕获到异常并不能代表消息就一定投递成功了。
一直到事务提交后都没有异常，确实就说明消息是投递成功了。但是，这种方式在性能方面的开销比较大，一般也不推荐使用。

发送端确认机制

RabbitMQ后来引入了一种轻量量级的方式，叫发送方确认(publisher confirm)机制。生产者将信道设置成confirm(确认)模式，一旦信道进入confirm 模式，所有在该信道上⾯面发布的消息都会被指派一个唯一的ID(从1 开始)，一旦消息被投递到所有匹配的队列之后（如果消息和队列是持久化的，那么确认消息会在消息持久化后发出），RabbitMQ 就会发送一个确认(Basic.Ack)给生产者(包含消息的唯一ID)，这样生产者就知道消息已经正确送达了。

RabbitMQ 回传给生产者的确认消息中的deliveryTag 字段包含了确认消息的序号，另外，通过设置channel.basicAck方法中的multiple参数，表示到这个序号之前的所有消息是否都已经得到了处理了。生产者投递消息后并不需要一直阻塞着，可以继续投递下一条消息并通过回调方式处理ACK响应。如果 RabbitMQ 因为自身内部错误导致消息丢失等异常情况发生，就会响应一条nack(Basic.Nack)命令，生产者应用程序同样可以在回调方法中处理理该 nack 命令。

	Connection connection = factory.newConnection();
	Channel channel = connection.createChannel();
	// Publisher Confirms
	channel.confirmSelect();
	channel.exchangeDeclare(EX_PUBLISHER_CONFIRMS, BuiltinExchangeType.DIRECT);
	channel.queueDeclare(QUEUE_PUBLISHER_CONFIRMS, false, false, false, null);
	channel.queueBind(QUEUE_PUBLISHER_CONFIRMS, EX_PUBLISHER_CONFIRMS,QUEUE_PUBLISHER_CONFIRMS);
	
	String message = "hello";
	channel.basicPublish(EX_PUBLISHER_CONFIRMS, QUEUE_PUBLISHER_CONFIRMS, null,message.getBytes());
	try {
   
		channel.waitForConfirmsOrDie(5_000);
		System.out.println("消息被确认：message = " + message);
	} catch (IOException e) {
   
		e.printStackTrace();
		System.err.println("消息被拒绝！ message = " + message);
	} catch (InterruptedException e) {
   
		e.printStackTrace();
		System.err.println("在不是Publisher Confirms的通道上使用该方法");
	} catch (TimeoutException e) {
   
		e.printStackTrace();
		System.err.println("等待消息确认超时！ message = " + message);
	}

waitForConfirm方法有个重载的，可以自定义timeout超时时间，超时后会抛TimeoutException。类似的有几个waitForConfirmsOrDie方法，Broker端在返回nack(Basic.Nack)之后该方法会抛出java.io.IOException。需要根据异常类型来做区别处理理， TimeoutException超时是属于第三状态（无法确定成功还是失败），而返回Basic.Nack抛出IOException这种是明确的失败。上面的代码主要只是演示confirm机制，实际上还是同步阻塞模式的，性能并不是太好。

实际上，我们也可以通过“批处理理”的方式来改善整体的性能（即批量量发送消息后仅调用一次waitForConfirms方法）。正常情况下这种批量处理的方式效率会高很多，但是如果发生了超时或者nack（失败）后那就需要批量量重发消息或者通知上游业务批量回滚（因为我们只知道这个批次中有消息没投递成功，而并不知道具体是那条消息投递失败了，所以很难针对性处理），如此看来，批量重发消息肯定会造成部分消息重复。

	Connection connection = factory.newConnection();
	Channel channel = connection.createChannel();
	// Publisher Confirms
	channel.confirmSelect();
	channel.exchangeDeclare(EX_PUBLISHER_CONFIRMS,BuiltinExchangeType.DIRECT);
	channel.queueDeclare(QUEUE_PUBLISHER_CONFIRMS, false, false, false,null);
	channel.queueBind(QUEUE_PUBLISHER_CONFIRMS, EX_PUBLISHER_CONFIRMS,QUEUE_PUBLISHER_CONFIRMS);
	
	int batchSize = 10;
	int outstandingConfirms = 0;
	String message = "hello";
	for (int i = 0; i < 102; i++) {
   
		channel.basicPublish(EX_PUBLISHER_CONFIRMS,
		QUEUE_PUBLISHER_CONFIRMS, null, message.getBytes());
		outstandingConfirms ++;
		if (outstandingConfirms == batchSize) {
   
			channel.waitForConfirmsOrDie(5_000);
			System.out.println("批消息确认");
			outstandingConfirms = 0;
		}
	}
	
	if (outstandingConfirms > 0) {
   
		channel.waitForConfirmsOrDie(5_000);
		System.out.println("批消息确认");
	}

另外，我们可以通过异步回调的方式来处理Broker的响应。addConfirmListener 方法可以添加ConfirmListener 这个回调接口，这个 ConfirmListener 接口包含两个方法:handleAck 和handleNack，分别用来处理 RabbitMQ 回传的 Basic.Ack 和 Basic.Nack。

还可以使用回调方法：

	Connection connection = factory.newConnection();
	Channel channel = connection.createChannel();
	// 启用Publisher Confirms
	channel.confirmSelect();
	channel.exchangeDeclare(EX_PUBLISHER_CONFIRMS,
	BuiltinExchangeType.DIRECT);
	channel.queueDeclare(QUEUE_PUBLISHER_CONFIRMS, false, false, false,null);
	channel.queueBind(QUEUE_PUBLISHER_CONFIRMS, EX_PUBLISHER_CONFIRMS,QUEUE_PUBLISHER_CONFIRMS);
	
	ConcurrentNavigableMap<Long, String> outstandingConfirms = new ConcurrentSkipListMap<>();
	
	ConfirmCallback cleanOutstandingConfirms = (sequenceNumber, multiple) ->
	{
   
		if (multiple) {
   
			System.out.println("小于等于 " + sequenceNumber + " 的消息都被确认了");
			// 获取map集合的子集
			ConcurrentNavigableMap<Long, String> headMap =
			outstandingConfirms.headMap(sequenceNumber, true);
			// 清空子集
			headMap.clear();
		} else {
   
			System.out.println(sequenceNumber + " 对应的消息被确认");
			String removed = outstandingConfirms.remove(sequenceNumber);
		}
	};
	
	channel.addConfirmListener(cleanOutstandingConfirms, (sequenceNumber,multiple) -> {
   
		if (multiple) {
   
			System.out.println("小于等于 " + sequenceNumber + " 的消息都 不确认了");
			ConcurrentNavigableMap<Long, String> headMap =
			outstandingConfirms.headMap(sequenceNumber, true);
		} else {
   
			System.out.println(sequenceNumber + " 对应的消息 不 确认");
			outstandingConfirms.remove(sequenceNumber);
		}
	});
	
	String message = "hello ";
	for (int i = 0; i < 1000; i++) {
   
		long nextPublishSeqNo = channel.getNextPublishSeqNo();
		channel.basicPublish(EX_PUBLISHER_CONFIRMS,
		QUEUE_PUBLISHER_CONFIRMS, null, (message + i).getBytes());
		System.out.println("序列号为：" + nextPublishSeqNo +