RabbitMQ 消息的可靠投递

mq 提供了两种方式确认消息的可靠投递

• confirmCallback 确认模式
• returnCallback 未投递到 queue 退回模式

 

在使用 RabbitMQ 的时候，做为消息发送方但愿杜绝任何消息丢失或者投递失败场景。RabbitMQ 为咱们提供了两个选项用来控制消息的投递可靠性模式。

rabbitmq 整个消息投递的路径为：
producer->rabbitmq broker cluster->exchange->queue->consumer

message 从 producer 到 rabbitmq broker cluster 则会返回一个 confirmCallback 。
message 从 exchange->queue 投递失败则会返回一个 returnCallback 。咱们将利用这两个 callback 控制消息的最终一致性和部分纠错能力。

 

对于消息异常，可使用如下方法进行解决

1. 使用RepublishMessageRecoverer这个MessageRecoverer会发送发送消息到指定队列
2. 给队列绑定死信队列，由于默认的RepublishMessageRecoverer会发送nack而且requeue为false。这样抛出一场是这种方式和上面的结果同样都是转发到了另一个队列。详见DeadLetterConsumer
3. 注册本身实现的MessageRecoverer
4. 给MessageListenerContainer设置RecoveryCallback
5. 对于方法手动捕获异常，进行处理

 

rabbitTemplate的发送流程是这样的：
1 发送数据并返回(不确认rabbitmq服务器已成功接收)
2 异步的接收从rabbitmq返回的ack确认信息
3 收到ack后调用confirmCallback函数
注意： 在confirmCallback中是没有原message的，因此没法在这个函数中调用重发，confirmCallback只有一个通知的做用。

 最安全的作法是是使用事务，可是这样效率就会很低，每秒钟处理的message在几百条左右。对于高性能的 mq 来讲是很是不可取的。

另外一种解决方法以下：在rabbitTemplate异步确认的基础上
1 在本地缓存已发送的 message
2 经过 confirmCallback 或者被确认的 ack，将被确认的message从本地删除
3 定时扫描本地的message，若是大于必定时间未被确认，则重发

这种解决方式也有必定的问题：
想象这种场景，rabbitmq接收到了消息，在发送ack确认时，网络断了，形成客户端没有收到ack，重发消息。（相比于丢失消息，重发消息要好解决的多，咱们能够在consumer端作到幂等）。

 

 

 

 

 

参考文献：

https://segmentfault.com/a/1190000016041620

https://www.jianshu.com/p/6579e48d18ae

https://github.com/littlersmall/rabbitmq-access/blob/master/src/main/java/com/littlersmall/rabbitmqaccess/MQAccessBuilder.java

https://www.jianshu.com/p/6579e48d18ae