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

一、概述

情景描述：

    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服务调用只能放在最后执行。

三个服务调用状况就是以下

 

三、收尾

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

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

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