分布式事务2PC TCC AT(Seata)

名词:

• TC 事务协调者
• TM 事务管理器
• RM 资源管理器

2PC 二阶段提交(Two-phaseCommit)

TC 给每个参与者发送预备请求，每个参与者要么能成功，要么不能成功，你要返回给TC，如果收到了每个参与者的成功消息，那么就发出commit指令，否则发送rollback。
这种方式最怕的就是其中一方由于网络延迟，卡顿等等造成让TC不知道是成功还是失败，这时候就会等待，而等待过程中，如果没有让参与者完成commit或rollback，那么就持续占有资源，直到完成。
XA协议采用两阶段提交方式来管理分布式事务。XA接口提供资源管理器与事务管理器之间进行通信的标准接口。XA协议包括两套函数，以xa_开头的及以ax_开头的。注意XA是已经实现2PC理论的协议，XA是XA，2PC是2PC，就和IOC和IOC容器的区别一样。

TCC

TCC分为3个阶段，Try,Commit,Cancle，Try阶段尝试是否能执行成功，如果可以就执行commit，否则rollback,需要业务提供这些方法实现，开发成本高。

具体实现：

每个表需要增加本地log表，如try commit cancle表，为了什么呢？

• 防止空回滚
• 防止悬挂(重复的try)
• 幂等校验

try阶段先要判断是否已经被存在在try commit cancle log中，如果存在，直接返回，为了上面那3点，需要有判断。然后扣减库存等等，如果执行成功添加到本地try_log表，然后调用下游服务，注意TCC事务发起者不要先去调用增加库存、金额等服务，因为这很可能造成无法回滚，在你增加的一瞬间被消费掉。
commit 阶段 不做事，只增加日志
cancle 阶段，同样先做幂等判断，然后执行回滚操作，回滚操作的原理就是根据try阶段进行反向操作，也就是事务补偿。

上面是上游服务tcc阶段，下游服务是try只增加日志，commit正式增加，cancle同样是反向操作。
有些有冻结字段的，原理相同，就是commit阶段改为正式更新。
为什么开发成本高，就是因为完完全全侵入到业务层，整体由应用控制，目前基本不会有人用，因为Seata出现了。

Seata

Seata原名Fescar，目前版本已经在生产模式下使用。
这里主要介绍 Seata的AT模式，Seata同样支持TCC等其他方式。

AT模式 (AsyncTransaction)

两阶段提交协议的演变：

• 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
• 二阶段：
  提交异步化，非常快速地完成。
  回滚通过一阶段的回滚日志进行反向补偿。

上面是seata官网的原话，什么意思呢？就是以前的2PC是整个事务过程中，只要不提交或回滚，就持续占有锁资源，而seata是异步方式，直接本地执行或回滚，本地事务提交前，先拿到该记录的 全局锁，本地提交释放本地锁，完全不需要去等其他业务一起commit，因为有Seata来管理这些，他会从log中判断是否回滚，如果回滚，根据日志执行事务补偿。锁占有的粒度细了，并发就会变高了。
它对业务的侵入性为0，你业务该怎么写就怎么写，就当只有这一个数据库的写就行了，只需要在配置中设置事务分组，和使用@GlobalTransaction，由Seata进行代理数据源@EnableAutoDataSourceProxy，如果光看业务层代码，你甚至不知道这是分布式事务。