远程调用时的分布式事物问题

Posted heaven-elegy

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了远程调用时的分布式事物问题相关的知识,希望对你有一定的参考价值。

前提

  • 所有服务均有独立的事物管理机制,相互间没有任何关联.
  • 所有业务接口都有对应的补偿方法,用于将已经更新的数据还原到上一次的状态.
  • 本次实例为同步业务,理想状态下,只有全部成功或全部失败两种情况.

正式开始

正常流程

技术图片

一切安好.

中途异常 - 补偿成功

技术图片

虽然发生了失败,但所有补偿都成功了.没有什么问题

中途异常 - 补偿失败

技术图片

此时,主服务有三种处理方法

  1. 主服务无限重试补偿方法,直到补偿成功.
    这里有很麻烦的问题,如果下游的服务器已经停机,此时主服务的无限重试已经没有意义.在最坏的情况下,如果主服务访问量过大,而因为业务相同,主服务的线程池中的全部线程将全部处于阻塞状态,失去处理新请求的能力.
    同时,访问主服务的客户端有可能会放弃本次的连接,导致正在重试中的线程被回收,丢失所有状态
  2. 主服务尽可能调用补偿方法,并回滚自身事物,同时通知备用方案
    这里依靠备用方案对失败的补偿调用进行异步异步调用,已达到"最终一致"的效果.备用方案一般需要集成"可靠消息系统"
  3. 主服务直接放弃补偿与自身的回滚,并通知备用方案
    与2基本相同.在调用链比较长的情况下且补偿随机性失败,从上层看,2方案的调用结果(备用方案未执行时)将成锯齿状.而本方案,其对应
    的消费者直接以级联方式进行补偿的调用,最终完成全部补偿调用与主方法数据回滚,同样从上层看,方案3的调用结果(备用方案未执行时)将是平整的(只有失败处断裂).

方案1直接pass
方案2,3可以使用消息队列与对应的消费者进行实现.但是会有短暂的数据不一致问题

中途异常(伪) - 触发补偿

技术图片

这种情况具体描述如下

  1. 正常远程调用
  2. 下游业务接收并进行处理
  3. 主服务认为网络超时(如等待数据库锁释放)或发生其他意外,从而触发补偿流程
  4. 下游业务完成请求处理
  5. 主服务发起并执行补偿流程(不包含4涉及的服务)

解决方法

  1. 记录全局唯一识别码,当主服务发起补偿时,所有下游业务应该得知,并出发各自的补偿方法.
  2. 需要注意,在尝试解决过程中,如果主服务过早推送回滚通知,涉及独自提交的服务早于对应业务处理完成进行补偿,将会导致回滚通知失效.

    在这种情况下,上游业务回滚,下游业务独自完成了业务处理,造成数据问题. 会有短暂的数据不一致问题

主服务断电 - 正常运行,补偿中,补偿失败中

技术图片
技术图片
此时主服务状态全部丢失且下游业务状态错乱

只能借用可靠消息对进行中的操作进行记录,并在再次开启后进行恢复

总结

  • 在必须要使用RPC进行远程调用且事物复杂的情况下,应使用一个可靠的消息系统保证在各方断电,断网,回滚时能够即使恢复"状态".
  • 同时,应保证严格的幂等性,对于非幂等消息,根据实际情况,进行保留会消耗.
  • 所有经由消息系统的恢复性调用,均为异步操作,此时各方数据会出现不同步的问题.
  • 对于复杂性,即使是只有2步,也会产生相同的情况.同样必须使用"可靠消息"系统进行保证.

以上是关于远程调用时的分布式事物问题的主要内容,如果未能解决你的问题,请参考以下文章

mq解决分布式事物问题

如何使用消息队列解决分布式事物?

Spring Cloud Alibaba Dubbo整合Seata(Fescar)实现分布式事物回滚

RabbitMq解决分布式事物

spring cloud 微服务之间feign接口调用,是怎么实现分布式事物的

SpringCloud-Seata分布式事物