99%的人都能看懂的MQ补偿机制

补偿机制的意义

假设有这样子一种场景:客户端请求 ---->空间结构微服务 ---->业主档案微服务 ---->房源微服务。这种调用链非常普遍。那么为什么需要考虑补偿机制呢?

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

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值