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解耦,并通过补偿机制保证我们数据的最终一致性是一个不错的选择。