分布式事务-1

分布式事务：

https://kaimingwan.com/post/fen-bu-shi/fen-bu-shi-shi-wu-de-dian-xing-chu-li-fang-shi-2pc-tcc-yi-bu-que-bao-he-zui-da-nu-li-xing

https://www.zhihu.com/question/31813039/answer/308847840

http://www.hollischuang.com/archives/1658

单数据库事务完全遵循ACID规范，属于刚性事务，

分布式事务要完全遵循ACID规范比较困难, 分布式事务属于柔性事务，满足BASE理论；

BASE描述： BA（Basic Availability 基本业务可用性）、S（Soft state 柔性状态）、E（Eventual consistency 最终一致性）；

现在业内比较常用的分布式事务解决方案主要有异步消息确保型、TCC、最大努力通知等。

柔性事务和刚性事务：

柔性事务满足BASE理论（基本可用，最终一致）

刚性事务满足ACID理论

分布式事务的典型处理方式:

2PC、TCC、异步确保和最大努力型

柔性事务：

两阶段提交（2PC）型

事务补偿型（TCC事务）

异步确保型

最大努力型

1、两阶段型

就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS，这是分布式环境下事务处理的典型模式。

2、补偿型

TCC型事务（Try/Confirm/Cancel）可以归为补偿型；

TCC思路是:尽早释放锁；在Try成功的情况下，如果事务要回滚，Cancel将作为一个补偿机制，回滚Try操作；

TCC各操作事务本地化，且尽早提交 (放弃两阶段约束)；当全局事务要求回滚时，通过另一个本地事务实现“补偿”行为；

TCC是将资源层的两阶段提交协议转换到业务层，成为业务模型中的一部分；

3、异步确保型

将一些同步阻塞的事务操作变为异步的操作，避免对数据库事务的争用；比如消息事务机制；

如，订单提交后的短信通知，将之前的阻塞操作变为异步，消息队列处理

4、最大努力通知型

通过通知服务器(消息通知)进行，允许失败，有补充机制；

如，支付成功，支付回调，直到响应成功

TCC：

https://my.oschina.net/fileoptions/blog/899991

Try: 尝试执行业务

完成所有业务检查(一致性)

预留必须业务资源(准隔离性)

Confirm:确认执行业务

真正执行业务，不作任何业务检查

只使用Try阶段预留的业务资源

Confirm操作要满足幂等性

Cancel: 取消执行业务

释放Try阶段预留的业务资源

Cancel操作要满足幂等性

TCC与2PC协议比较：

位于业务服务层而非资源层

没有单独的准备(Prepare)阶段， Try操作兼备资源操作与准备能力

Try操作可以灵活选择业务资源的锁定粒度(以业务定粒度)

较高开发成本

TCC示例：

分别位于三个不同分库的帐户A、B、C，A和B一起向C转帐共80元：分布式事务之说说TCC事务

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冻结的金额即可。

3、Cancel：取消执行业务

释放Try阶段预留的业务资源：如果Try阶段部分成功，比如帐户A的余额够用，且冻结相应金额成功，帐户B的余额不够而冻结失败，则需要对帐户A做Cancel操作，将帐户A被冻结的金额解冻掉。