基于关系型数据实现分布式事务方案

分布式、集群、高并发，这已经成了稍微大点互联网系统必须具备的关键词。但是新的方法引入了新的问题，其中分布式事务是每个分布式系统绕不开的话题。各种分布式事务的解决方案也层出不穷，但万变不离其宗，基本基于两种方案理论：cap理论或base理论（对这两种理论的具体内容不太了解的读者朋友请自行查找相关资料）。
笔者本次提出的基于关系型数据库实现的分布式事务解决方案基于base理论。基于cap理论的解决方案存在分布式锁的问题，在系统性能上一直是个问题，因此一般高并发的大型互联网系统不采用该理论下的方案。
文中提出的分布式事务方案是笔者在以往一个支付项目所使用的实现方案（原方案全部由java实现）。由于关系到一些商业秘密，笔者不提供具体的实现代码，只给出相关的解决方案。
本方案实现主要基于备忘录模式和业务补偿机制。实现方案依次如下:
1.创建事务库。
事务库有两个主要表主干事务表main_trans和分支事务表sub_trans。
main_trans主要的数据结构为

sub_trans主要的数据结构为

2.处理流程
下面以两个方法方法A和方法B为例（多个方法处理方式类似）。方法A与方法B分处不同的服务中，服务均连接不同的数据源数据源A和数据源B。
1.请求相关参数事务表：将方法A的参数、url、业务id写入和方法B的参数、url、业务id（全局必须唯一）写入分支事务表及创建主事务表。所有状态均为未开始。（需要说明的是如果事务类型是cancel回滚事务，相关参数需要取反，比如本来需要账户+300，这里的参数应取-300以便后面异常回滚）
2.分别组装参数异步提交方法A和方法B（异步提交主要为了提高系统的吞吐率）。
3.在方法A中执行方法，执行完成后，以业务记录id更新分支事务表状态为已完成。查询该分支事务表的主干事务表下是否还有未完成的分支事务，如果还有未完成的分支事务，将主干事务状态改为处理中，否则改为已完成。在方法B中同样如此。
4.主干事务表状态为已完成表明整个分布式事务已完成。

3.业务补偿
对于未完成的分布式事务需要进行业务补偿。
业务补偿需要创建定时任务。定时任务的频率需要依据实际情况而定。处理流程如下:
1.扫描事务库的主干事务表，查出状态不为已完成的n时间前主干事务表记录。
2.遍历循环查询到的主干事务表记录，如果事务类型为create，查询出未执行的分支事务记录。如果事务类型为cancel，查询出已执行完毕的分支事务记录。
3.根据查询到的分支事务记录，应用反射机制，组装参数和url，重新执行方法的远程调用。
4.方法执行完成后，以业务记录id更新分支事务表状态为已完成。查询该分支事务表的主干事务表下是否还有未完成的分支事务，如果还有未完成的分支事务，将主干事务状态改为处理中，否则改为已完成。
5.主干事务表状态为已完成表明整个分布式事务已完成。
注意：所有方法都要实现幂等性。否则会出现严重的问题

4.执行流程图

以上就是笔者基于关系型数据实现分布式事务方案的相关内容。该方案实现了分布式事务完全可控，数据最终一致性，事务异步处理等几大问题。由于采用了base理论，高并发的互联网系统可借鉴该方案。但该方案过于依赖数据库，对性能会有一定的损失，并且对业务实现有侵入性（比如业务记录id需要记录在分支事务表里及请求参数及远程url手动写入事务表），使用时请根据实际情况慎重选择。