分布式服务-DUBBOX(九):多服务串行调用，解决分布式事务问题

2019独角兽企业重金招聘Python工程师标准>>>

1、概述

情景描述：

    dubbo服务A：支付接口服务

    dubbo服务B：订单状态更新

正常流程，首先调用支付接口，支付成功后，再调用dubbo服务B更新订单状态；但是如果在调用dubbo服务B时失败，此时dubbo服务A中数据已无法回滚（事务已提交），此时该如何进行处理?

 

• 方案一：

    手动编写dubbo服务A回滚代码，在dubbo服务B调用失败时，进行该回滚代码调用，此方案只使用简单业务场景、冗余代码多。

• 方案二：

    使用JTA分布式事务，但这样不好的就是代码入侵性高以及性能问题。（本人也没有用过，网上这么讲的）。

• 方案三：

    结合MQ消息中间件实现的可靠消息，来到达数据最终一致性（CAP理论）。

 

2、折中方案

    方案一不理想，方案二、三相关技术没具体接触过。

    下图是项目中遇到的折中方案：

    也就是说“dubbo服务A”即是提供者也是消费者（dubbo服务B的调用），只有在"dubbo服务B"调用成功的情况下才会对“dubbo服务A”事务提交。

    局限：

• 即是生产者又是消费者的dubbo服务，只能进行“唯一”dubbo服务调用。
• 而这个“单一”dubbo服务调用只能放在最后执行。

三个服务调用情况就是如下

 

3、收尾

    至此，关于分布式服务框架-dubbo总结完毕！

     额外提下，之前demo工程中主键id采用的数据库自增，在“分布式”局限性

• 分布式服务中，重试机制下容易造成数据重复。
• 存在主外键依赖的情况下，外键设值麻烦。
• 不再适用于拆表拆库。

    

转载于:https://my.oschina.net/u/2526015/blog/806218