补偿机制的意义
假设有这样子一种场景:客户端请求 ---->空间结构微服务 ---->业主档案微服务 ---->房源微服务。这种调用链非常普遍。那么为什么需要考虑补偿机制呢?
一次跨机器的通信可能会经过DNS 服务,网卡、交换机、路由器、负载均衡等设备,这些设备都不一定是一直稳定的,在数据传输的整个过程中,只要任意一个环节出错,都会导致问题的产生。而在分布式场景中,一个完整的业务又是由多次跨机器通信组成的,所以产生问题的概率成倍数增加。
但是,这些问题并不完全代表真正的系统无法处理请求,所以我们应当尽可能的自动消化掉这些异常。那么当某个操作发生了异常,如何通过内部机制将这个异常产生的「不一致」状态消除掉。
事务补偿
事务补偿则代表着整个事务进行回滚和失败,则最终结果会失败。
重试
重试和补偿不太一张,重试有一定机会处理成功。
基于RabbitMQ的自动补偿机制
在RabbitMQ里,如果消费者在处理消息时,业务逻辑出现异常,默认会执行补偿机制(也就是消息重试机制)。如果业务逻辑出现异常,是不会消费消息的。
我们先在消费者处理消息的地方模拟一个异常:
生产者发送消息给消费者,会发现控制台一直在打印错误日志,也就是说,消费者一直在重试消费(补偿):
接下来我们去RabbitMQ控制台看一下消息是否被成功消费,从控制台可以看出,我们是的消息是没有被成功消费的:
那么RabbitMQ消费者的补偿原理是怎样的呢?
- @RabbitListener 底层使用了AOP进行拦截,如果程序没有抛异常,自动提交事务。
- 如果AOP使用异常通知拦截获取异常信息的话,自动实现补偿机制,该消息会缓存到RabbitMQ服务端进行缓存,一直重试到不抛异常为准。
其实在application.yml配置文件可以配置重试的次数与时间的,如重试5次,每次3秒:
加好配置之后,再次运行程序,发现重试了5次,3秒重试一次,而且RabbitMQ控制的消息也消费了。
基于人工补偿机制
上面说到了基于MQ的补偿机制,但其实思想也是重试机制,但是重试机制也有可能最终失败,所以针对这种场景我们还是需要人工干预,保证我们的MQ消费成功。
- 创建一个MQ消费记录表
- MQ消费伪代码
- 最后引入定时任务,去MQ消费记录表找到消费失败的消息体进行补偿,保证最终一致性。
如何合理选择重试机制
下面有两种情况:
- 情况一:消费者获取到消息后,调用第三方接口,但接口暂时无法访问,是否需要重试? (需要重试机制)
- 情况二:消费者获取到消息后,抛出数据转换异常,是否需要重试?(不需要重试机制)。
对于情况一是需要重试机制的,因为第三方API接口无法访问可能是多种原因造成的,比如网络延时等。而情况二不需要重试机制,因为异常的代码是一直都会有异常的,只能通过下一次发布版本解决。
总结
引入MQ确实有利于系统解耦,但同时也增加了系统架构的复杂和运维成本。在分布式系统中使用MQ,并且想好补偿方案是非常重要的,对于数据一致性要求较高的不建议引入MQ,对数据一致性要求不高的系统中我们可以通过MQ解耦,并通过补偿机制保证我们数据的最终一致性是一个不错的选择。