【分布式事务】微服务架构下的分布式事务问题

时间：2018-10-02 17:23:27 阅读：258 评论：0 收藏：0 [点我收藏+]

标签：try 驱动 fir width 分代 github 复制支付 action

一、基本概念

ACID理论：关系型数据库的事务满足 ACID 的特性，具有 ACID 特性的数据库支持数据的强一致性，保证了数据本身不会出现不一致。适用于传统的单体架构。
CAP理论：在分布式系统下，包含三个要素：Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），并且三者不可兼得。分布式系统要求保证分区容错性，只能在数据强一致性（C）和可用性（A）之间做平衡，即选择CP或者AP。比如Zookeeper为CP系统保证强一致性牺牲一定的可用性；Eureka为AP系统保证较高可用性牺牲一定的一致性。另外，CAP理论中是忽略网络延迟，也就是当事务提交时，从节点A复制到节点B，但是在现实中这个是明显不可能的，所以总会有一定的时间是不一致。所以CAP一般适用于局域网系统的理论基础。
BASE理论：解决 CAP 理论中分布式系统的可用性和一致性不可兼得的问题，提出最终一致性。即，最终数据是一致的就可以了，而不是实时保持强一致。例如，支付成功，订单也成功，但增加积分失败，此时，不应回滚支付和订单，而应通过一些补偿方法来让积分得以正确地增加。

二、解决方案

方案	解决思路	适用场景	说明
本地事务	基于数据库的ACID理论基于undo、redo日志记录 undo日志实现回滚、redo日志实现commit场景异常的恢复	传统单体架构分布式事务要求不高的场景	分布式系统场景出现问题怎么办？日志记录--监控告警–人工干预修复问题溯源，例如：维修工单可以创建，但是维修费用调用失败导致整个事务回滚可能维修费用自身问题，如性能压力过大导致请求时，触发调用失败回滚可能维修费用操作依据成功了，但是返回
两阶段提交	基于XA协议，依赖TM、RM的交互，依赖数据库的能力 TM存在单点故障，锁资源占用时间较长	面向多数据源或者分布式数据库设计（XA本质是TM与RM之间的规范）适用于多数据源的架构 Mycat也实现了XA协议，一些公司的分布式事务使用该方案，但是应用层非微服务架构适用于并发量不大，处理时间较短的核心交易业务场景	XA协议：
三阶段提交	基于TCC协议在数据库外部实现事务机制达到最终一致性牺牲了应用的灵活性，需要提供Try、Confirm、Cancel的具体实现，且需要小心保证幂等操作	跨应用，但需要实现TCC接口，对已有系统侵入较大，适用于新系统不强依赖数据库特性，TCC是一个通用的模型参考实现：https://github.com/liuyangming/ByteTCC/	TCC协议：
可靠消息模式	大事务转变为小事务，小事物之间的不一致通过额外的轮训任务进行补偿该思路最初由Ebay提出：https ://queue.acm.org/detail.cfm?id=1394128 可分为基于本地事件、基于外部事件两种模式业务逻辑需要保证幂等性	适用于核心模块的改造，或者完全基于消息驱动的架构，否则对已有系统入侵较大另外，如果需要回滚，超过两个实务操作的场景比较复杂，所以这种场景需要遵守最终一致性原则，失败不会滚，直到补偿成功依赖具备事务功能的消息系统或者数据库，如：RabbitMQ、Kafka、RocketMQ等	基于本地事件：基于外部事件：
可靠消息变种	不依赖消息队列通信，将消息队列的功能包装为Rest服务，屏蔽消息队列的接口将基于可靠消息模式对架构和应用入侵的缺点降低	最大努力通知型如支付宝的回调机制，可以设置指数时间重试，参考阿里实现：https://zhuanlan.zhihu.com/p/26114119
可靠消息变种		下游应用轮询如微信的轮询机制，由下游应用自己保证一致性
SAGA方案	基于工作流的思路，原理：https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf 定义顺序操作、回滚操作的流程，交给事务协调器统一管理一些应用框架实现了该方案，如CQRS框架Axonframework：https://github.com/AxonFramework/AxonFramework，又如华为servicecomb：https://github.com/apache/incubator-servicecomb-saga	应用方定义工作流，交给SAGA进行管理，虽然这种方案不火热，但是对应用入侵较小，且符合分层的设计原则，添加一个composite层单独实现需要分布式事务的流程即可	SAGA工作流：
阿里GTS	优化XA架构的路线，使用上与XA类似，业务入侵较小，添加注解 GTS参考：https://zhuanlan.zhihu.com/p/32684212 仿GTS实现：https://github.com/wxbty/meepo https://github.com/chenjy16/gts 与GTS类似的：https://github.com/codingapi/tx-lcn 看起来最成熟的开源方案	适用于阿里云方案，专线也可以接入使用，第三方系统遵循TCC的也可以接入
总结建议	如果非必要，不引入分布式事务，每个微服务保证自身的高可用，基本能够保证数据的一致性，极端的情况除外。--事实上微服务的架构BAT十年前就在使用，没有分布式事务也一样，因为基础设施、每个微服务自身可用性比较高，所以不需要引入更大的复杂性如果必要，首先保证核心业务的数据一致性，比如交易业务，可以采用消息机制、最大努力通知、轮询机制的方案，他们的本质都是记账，即使出了问题也有据可查--这部分一般借助第三方支付系统的能力即可满足如果只是较少量的业务需要分布式事务特性，可以局部使用基于可靠消息的方案，参考：https://github.com/vvsuperman/coolmq，这种方案需要注意很多细节，理论上每个环节都可能出现网络异常，都需要有相应的措施保障，比如：如果建立指数时间重试机制，下游服务接口需要保证幂等，该方案相当于业务自己负责维护一致性如果大量业务需要分布式事务，也可以引入类似DelayMq的服务做解耦，利用该服务提供回调服务将服务链串联起来（消息中包含回调的Url、参数），但是下游的服务接口需要保证幂等性--PaaS平台可以提供类似的服务，参考：https://zhuanlan.zhihu.com/p/26114119。该方案需要能够接受部分代码的重构如果大量业务需要分布式事务，可以引入类似GTS对业务入侵较小的框架，避免更新架构和代码，代码添加必要的注解即可，如：https://github.com/codingapi/tx-lcn --开源方案，建议经过测试之后谨慎上线，这个能力也可以研究下看看能不能做到PaaS平台数据一致性是一个系统工程，仅仅在事务框架层面解决是不够的，还需要配套的规范措施--如请求RequestID、链路追踪、接口幂等、日志输出规范、关键日志记录规范等，出现问题可以快速定位，这部分的数据可以让PaaS接管，提供链路服务、监控告警服务等完善基础设施，降低网络问题的影响是重要前提。对于实际调用已经成功，返回时网络异常的问题，需要补偿机制--PaaS可以提供类似DelayMq的服务完善应用的监控告警设施，如应用的API、访问次数、失败次数等监控，及时告警--PaaS可以提供应用的实时监控告警能力