分布式事务两阶段提交和三阶段提交

分布式事务

两阶段提交

基于XA架构，采取强一致性，遵从acid

有两个角色： 一个全局事务管理者(Transaction manage) 也叫协调者和多个局部资源管理者(resource manage) 也叫参与者

1.请求提交阶段/投票阶段 （commit-request phase/ voting phase）

协调者询问参与者是否可以正常执行，让参与者准备提交事务，参与者执行sql操作，反馈执行结果，但事务不提交。

2.提交阶段/决策阶段（commit phase）

协调者根据第一阶段的投标结果，汇总决定事务是提交还是回滚。当前所有的参与者提交的状态是同意，事务才会提交，只要有一个又问题，事务就会回滚。

二阶段存在的问题

1.同步阻塞问题---- 在执行过程中，参与者占用公共资源，其他第三方节点访问，处于阻塞的状态

2.单点故障问题----- 协调者单点故障问题

3.数据不一致问题----协调者出现问题，只通知了部分参与者，只有部分参与者进行了事务的提交，导致事务的不一致。

三阶段提交

引入 预询问策略和超时检测，减少集群的阻塞策略

1.canCommit阶段

2.prepareCommit 阶段

3.doCommit 阶段

 

TCC分布式事务机制，保证数据的一致性

try comfirm cancel 三个接口

三个阶段

try 阶段 锁定某个资源，设置一个预备类的状态，冻结部分数据。

confirm 阶段 try 阶段执行成功，执行confirm

cancel try阶段执有异常，执行cancel

TCC 事务会记录一些分布式事务的日志

国内开源的TCC分布式事务框架： ByteTCC，TCC-transaction，Himly

 

 

可靠消息最终一致性方案实现的分布式事务

使用rocketmq 实现

rocketmq 解决了一下的问题

1.本地事务与消息发送的原子性操作

2.事务参与方接受消息的可靠性

 

 

基于消息队列的柔性事务

本地事务+定时任务+消息队列+事件表

参考：

1.https://seata.io/zh-cn/docs/overview/what-is-seata.html----seata中文文档

2.https://www.cnblogs.com/binyue/p/3678390.html---- 二阶段提交/三阶段提交

3.https://www.jianshu.com/p/bfd433bf8429----两阶段提交/三阶段提交

4.https://www.cnblogs.com/jajian/p/10014145.html----TCC事务

5.https://www.cnblogs.com/haizai/p/11954339.html-----可靠消息最终一致性的分布式解决方案