【基于唯品会MP平台】分布式事务解决方案

背景

事务对于一个系统来说是非常重要的，分布式事务一直是一个老生常谈的问题。

本地事务由数据库本身ACID特性保证，数据库管理系统采用日志来保证事务的原子性、一致性和持久性。日志记录了事务对数据库所做的更新，如果某个事务在执行过程中发生错误，就可以根据日志，撤销事务对数据库已做的更新，使数据库退回到执行事务前的初始状态。

分布式事务，目前圈内存在的解决方案也很繁杂。但是无非在跟CAP原则作斗争。

CAP指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

 

分析

基于CAP和BASE理论，通常分布式的解决方案思路分为：2PC/3PC（分段提交协议），TCC（补偿机制），Eventually consistent（事务最终一直性）。下面我们一个个拿来分析。

2PC，2pc涉及到2个阶段，3个操作： 
阶段1：“准备提交”。事务协调者向所有参与者发起prepare，所有参与者回答yes/no。 
阶段2：“正式提交”。如果所有参与者都回答yes，则向所有参与者发起commit；否则，向所有参与者发起rollback。

对应的实现层面，也就是XA协议。XA被许多数据库（如Oracle和DB2）和中间件等工具(如CICS 和 Tuxedo)本地支持 。当然，也可以选择自己实现事务协调器（http://www.dczou.com/viemall/407.html）。

存在问题：1、同步阻塞：最大的问题即同步阻塞，即：所有参与事务的逻辑均处于阻塞状态。2、单点：协调者存在单点问题，如果协调者出现故障，参与者将一直处于锁定状态。3、脑裂：在阶段2中，如果只有部分参与者接收并执行了Commit请求，会导致节点数据不一致。3PC多了一步CanCommit在prepare前。其实，无论是2PC还是3PC，应用场景在企业级应用没什么问题。

TCC服务是由Try/Confirm/Cancel业务构成的，说白了就是补偿机制。简单的理解可以，预留出状态回滚的接口，在远程调用时，发生失败时，再进行回调补偿接口也就是Cancel，从而让数据接口之间实现幂等性。现有成熟的框架TCC-Transaction（https://blog.csdn.net/X5fnncxzq4/article/details/79235790）。

Eventually consistent，最终一致性。一般来说就是利用消息队列来实现，将生产者作为事务发起端，消费者作为事务另一端。事务保障的压力是丢给了MQ。所以，所选择的MQ必须有落盘，可高可用性稳定性的保障。

解决方案

一般解决方案都是根据特定场景选择其中合适的解决方案，没有最优解。几个月前，做了一套分布式事务组件，利用最终一致性+定时任务补偿处理的。

最终一致性部分，用到的是DelayQueue来处理，考虑到，调用失败可能是由于远程接口网络阻塞，或者远程接口流量高峰造成的响应失败等等。延时处理可以配置delayTime避免这些问题（延时时间的配置，一定要考虑到QPS的问题，DelayQueue里积压的data=QPS*delayTime）。当然，可以设置tryNum来配置尝试的次数。如果超过次数仍然失败，就落到定时的DB中，进行定时任务补偿处理，定时任务框架我们是根据当当Elastic Job的改造的。当然，没有资源限制，DB可以选择分布式存储服务更优。另外，考虑到一些异常数据引起的，有条件的话可以在定时任务的table里加一个记录定时任务发送次数，当超过次数的失败数据为红线数据，要短信或邮件发送给相应平台的负责人，去定位问题。源码：https://github.com/BingShao001/fish-util