由浅入深了解分布式事务技术-基本概念篇

本文介绍常见的分布式事务技术方案

3PC

Three-phase commitThree-phase commit protocol2PC

1、引入超时机制。同时在协调者和参与者中都引入超时机制。

2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有canCommit、PreCommit

CanCommit阶段

3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，

PreCommit阶段

中断事务协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时)，那么就会执行中断事务。

doCommit阶段

如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。(其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了PreCommit请求，

那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前，收到所有参与者的CanCamit响应都是Yes。当进入第三阶段时，由于网络超时等原因,虽然参与者没有收到commit或者abort响应，但是他有理由相信:成功提交的几率很大。

TCC

TCC型事务（Try/Confirm/Cancel）可以归为补偿型；TCC思路是:尽早释放锁；在Try成功的情况下，如果事务要回滚，Cancel将作为一个补偿机制，回滚Try操作； TCC各操作事务本地化，且尽早提交 (放弃两阶段约束)；当全局事务要求回滚时，通过另一个本地事务实现“补偿”行为；

务拆分的业务场景如下，分别位于三个不同分库的帐户A、B、C，A和B一起向C转帐共80元：

1、Try：尝试执行业务。

完成所有业务检查(一致性)：检查A、B、C的帐户状态是否正常，帐户A的余额是否不少于30元，帐户B的余额是否不少于50元。

预留必须业务资源(准隔离性)：帐户A的冻结金额增加30元，帐户B的冻结金额增加50元，

这样就保证不会出现其他并发进程扣减了这两个帐户的余额而导致在后续的真正转帐操作过程中，帐户A和B的可用余额不够的情况。

2、Confirm：确认执行业务。

真正执行业务：如果Try阶段帐户A、B、C状态正常，且帐户A、B余额够用，则执行帐户A给账户C转账30元、帐户B给账户C转账50元的转帐

操作。

不做任何业务检查：这时已经不需要做业务检查，Try阶段已经完成了业务检查。

只使用Try阶段预留的业务资源：只需要使用Try阶段帐户A和帐户B冻结的金额即可。

Confirm系统层面是必然成功，不成功重试机制！支持幂等

3、Cancel：取消执行业务

释放Try阶段预留的业务资源：如果Try阶段部分成功，比如帐户A的余额够用，且冻结相应金额成功，帐户B的余额不够而冻结失败，则需

要对帐户A做Cancel操作，将帐户A被冻结的金额解冻掉。

TCC主流实现方案

基于消息的分布式事务

一种异步事务机制、只能保证最终一致性；

但可用性非常高，不会因为故障而发生阻塞。另外，主事务已经先行提交，如果因为从事务无法提交，

要回滚主事务还是比较麻烦，所以这种模式只适用于理论上大概率等成功的业务情况，

即从事务的提交失败可能是由于故障，而不大可能是逻辑错误。

本地消息表

基于本地消息表的方案是指将消息写入本地数据库，通过本地事务保证主事务与消息写入的原子性。

本地消息表这种实现方式应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行处理，这种思路是来源于ebay

事务消息

事务消息依赖于支持“事务消息”的消息队列，其基本思想是

利用消息中间间实施两阶段提交，将本地事务和发消息放在了一个分布式事务里，保证要么本地操作成功成功并且对外发消息成功，要么两者都失败。

分布式事务方案对比