分布式事务-基础内容说明

个人觉的分布式事务思路不复杂，主要是场景多，如何结合场景选择技术比较复杂，如何不局限于现有的解决方案，去做创新也是一个思路。

 

问题根源就是请求和响应如何让其它节点去感知，由于网络的传输的复杂性，总会有百分之几的概率问题，深究这些问题，有时候会陷入一种死循环无解的状态。

1.单机事务

开启事务、执行事务、提交事务三个动作在单体应用中很简单，要么成功要么失败做到原子性的比较容易。

2.集群中分布式事务解决方案

2pc提交，核心通过引入协调者来进行各节点事务的协调和同步，通过下图完整描述一个请求从开始到结束整个2pc的提交过程。

3.TCC事务

Tcc事务和2pc区别是：
TCC先预留在确认执行，主要是在应用层面进行，通过代码层面锁机制进行实现。
2PC是先准备、在执行，需要协调者参与，倾向于数据库层面。

TCC编程模式
如果你将应用看做资源管理器的话,TCC是应用层的2PC(2 Phase Commit, 两阶段提交)，应该是三个英文单词的首字母缩写而来。没错，TCC分别对应Try、Confirm和Cancel三种操作，这三种操作的业务含义如下：

Try：预留业务资源
Confirm：确认执行业务操作
Cancel：取消执行业务操作

稍稍对照下关系型数据库事务的三种操作：DML、Commit和Rollback，会发现和TCC有异曲同工之妙。在一个跨应用的业务操作中，Try操作是先把多个应用中的业务资源预留和锁定住，为后续的确认打下基础，类似的，DML操作要锁定数据库记录行，持有数据库资源；Confirm操作是在Try操作中涉及的所有应用均成功之后进行确认，使用预留的业务资源，和Commit类似；而Cancel则是当Try操作中涉及的所有应用没有全部成功，需要将已成功的应用进行取消(即Rollback回滚)。其中Confirm和Cancel操作是一对反向业务操作。

详细来说
1、Try：尝试执行业务。

完成所有业务检查(一致性)
预留必须业务资源(准隔离性)

2、Confirm：确认执行业务。

真正执行业务
不做任何业务检查
只使用Try阶段预留的业务资源

3、Cancel：取消执行业务

释放Try阶段预留的业务资源
TCC事务需要通过业务操作来实现分布式事务，开发成本较高，对开发人员要求对事物详细了解，才能开发出高效的事务。

对应代码层面需要开发三套API（冻结预留、生效执行、撤销取消）对此进行操作。