Spring-RabbitMQ-自动补偿机制

1. 自动补偿机制

在RabbitMQ里，如果消费者在处理消息时，业务逻辑出现异常，默认会执行补偿机制（也就是消息重试机制）。如果业务逻辑出现异常，是不会消费消息的。基于上一篇博客的例子《消息中间件系列教程（13） -RabbitMQ-SpringBoot集成RabbitMQ》来演示一下。

现在消费者处理消息的地方模拟一个异常：

生产者发送消息给消费者，会发现控制台一直在打印错误日志，也就是说，消费者一直在重试消费（补偿）：

也可以在RabbitMQ控制台看到，消息时没有被消费的：

那么RabbitMQ消费者的补偿原理是怎样的呢？

@RabbitListener 底层使用了AOP进行拦截，如果程序没有抛异常，自动提交事务。
如果AOP使用异常通知拦截获取异常信息的话，自动实现补偿机制，该消息会缓存到RabbitMQ服务端进行缓存，一直重试到不抛异常为准。
其实在application.yml配置文件可以配置重试的次数与时间的，如重试5次，每次3秒：

 运行程序后，发现重试了5次，3秒重试一次，而且RabbitMQ控制的消息也消费了：

基于人工补偿机制

上面说到了基于MQ的补偿机制，但其实思想也是重试机制，但是重试机制也有可能最终失败，所以针对这种场景我们还是需要人工干预，保证我们的MQ消费成功。

创建一个MQ消费记录表

 MQ消费伪代码

3、如何合理选择重试机制

下面有两种情况：

情况1: 消费者获取到消息后，调用第三方接口，但接口暂时无法访问，是否需要重试? （需要重试机制）
情况2: 消费者获取到消息后，抛出数据转换异常，是否需要重试?（不需要重试机制）。
对于情况一是需要重试机制的，因为第三方API接口无法访问可能是多种原因造成的，比如网络延时等。而情况二不需要重试机制，因为异常的代码是一直都会有异常的，只能通过下一次发布版本解决。

总结

引入MQ确实有利于系统解耦，但同时也增加了系统架构的复杂和运维成本。在分布式系统中使用MQ，并且想好补偿方案是非常重要的，对于数据一致性要求较高的不建议引入MQ，对数据一致性要求不高的系统中我们可以通过MQ解耦，并通过补偿机制保证我们数据的最终一致性是一个不错的选择。