分布式事务

分布式事务

2PC

一阶段：
事务的协调者向所有的事务参与者发起prepare请求，参与者接收到请求之后，执行本地事务更新，但是暂时不提交。返回完成消息给事务协调者，
事务协调者受到消息之后开启二阶段。
二阶段：
事务协调者收到所有的参与者的完成消息之后，通过所有的参与者Commit本地事务，事务参与者各种提交本地事务，释放资源，向事务协调者反馈完成
消息。都全部完成之后，整个分布式事务完成。。

存在问题：
1.性能问题
XA协议追求强一致性，只有所有的节点准备完成才会通知提交，性能很差。
2.协调者单点故障
事务协调者节点如果挂掉之后，整个事务就会出错
3.数据不一致问题
在二阶段中，如果因为网络问题，一些事务的参与者没有收到commit消息，一些事务收到提交，会导致节点之间的数据不一致问题

3PC

三阶段CanCommit
事务参与者一直没有收到commit提交消息，引入CanCommit超时机制，本地会自动提交。解决了2PC的协调者单点故障问题，但是还是没有解决性能和不一致问题。

TCC

try
事务提交前的检查，预留好资源
commit
确定执行业务操作，对try阶段预留的资源正式执行。
cancel
取消执行业务操作，对try阶段预留的资源释放。

RocketMQ事务

1.消息发送方先发送一个半消息。此时消费端不能消费
2.发送成功之后，执行本地事务
3.本地事务执行成功之后，消息发送方会提交半消息，此时消费端可以消息。

问题：如果发送预备消息成功，执行本地事务成功，但发送确认消息失败；这个就有问题了，因为用户A扣款成功了，
但加钱业务没有订阅到确认消息，无法加钱。这里出现了数据不一致。

MQ提供状态会查机制，会定时遍历commitlog中的半消息，可以在会查的时候查询本地事务是否提交成功，如果成功则提交半消息，消费端可以消费。

Seata

AT模式
执行流程
1.TM向TC申请开启一个全局事务，TC返回一个唯一的全局事务XID
2.RM向TC注册分支事务，并把它纳入到全局事务XID管理，返回分支事务branceId
3.RM执行本地事务，操作数据库，记录数据操作前后的镜像，连同XID branceId 记录到undo_log表中
4.RM执行成功后远程调用两一个分支事务,传播XID到另一个分支事务
5.另一个分支事务继续向TC注册本地事务，加入到XID对应的全局事务中，返回分支事务branchId
6.执行本地事务，操作数据库，记录数据操作前后的镜像，连同XID branchId 记录到undo_log表中
7.全局事务链路处理完成之后，TM向TC发起全局事务的提交或回滚
8.TC管理所有的分支事务，决定是否需要回滚