分布式事务

定义

问题：

分布式事务是为了解决分布式系统（微服务）中不通节点数据不一致的问题。

场景：

分布式系统中，对同一业务的操作分布在不通的系统中，在单体系统的事务处理满足不了分布式系统的发展。

例如：购物系统中的订单和库存在不同的微服务中。

分布式事务原理

1. 2pc 两阶段提交
2. 3pc 三阶段提交 都属于oracle提出的xa协议
3. tcc事务 try commit cancel
4. mq事务 利用消息中间件来完成事务的后一半更新 实现系统的一致性。

两阶段提交

xa协议中包含事务的参与者和 事务的协调者

• 第一阶段（请求/表决阶段）：协调者向参与者分贝发送事务预处理请求（prepare）;参与者收到命令后，各自打开本地数据库事务，开始执行本地事务，但是不会马上提交事务，而是写入undolog和dolog，向协调者返回成功或者失败信息。

如果所有的参与者节点都向协调者作了“Vote Commit”的反馈的话，那么此时流程就会进入第二个阶段了。

• 第二阶段（提交/执行阶段）正常流程：
  

所有节点返回确认信息，协调者向所有参与者节点发出"全局确认通知（global_commit）"；各节点完成本地事务提交，并将结果（ack）消息返回给协调者，协调者向调用方反馈分布式事务处理完成结果。

• 第二阶段（提交/执行阶段）异常流程：
  
  相反，如果在请求确认阶段有参与者节点不能完成事务，这协调者会向所有节点发送事务回滚消息（global_rollback），参与者根据undo log各自回滚本地事务，释放资源，向协调者发送ack消息，协调者向调用者反馈分布式事务处理失败的结果。

xa两阶段提交的不足

• 性能问题

xa协议遵循强一致性。在事务执行过程中，各节点占用数据库资源，只有当所有节点准备完毕，才会释放资源。有着明显的性能问题

• 协调者性能问题

事务协调者是xa模型的核心，如果他挂掉，参与者收不到提交或则回滚的消息，会一直处于中间状态 本地事务挂起。

• 参与者丢失消息导致不一致问题

在xa协议的第二阶段，如果网络通信问题，一部分参与者受到提交消息，一部分没收到提交信息，导致节点之间数据的不一致。

xa协议三阶段提交

三阶段提交在两阶段提交的基础上进行了的cancommit阶段，并且引入了超时机制。一旦事务参与者超时没收到协调者的命令，会自动提交。但是这只解决了协调者单点故障，没有解决性能问题和数据一致性问题

MQ事务

利用消息中间件完成事务的后一半提交，实现系统的一致性，避免了了XA协议的性能问题。

TCC事务 补偿操作

try commit cancel 其逻辑类似于xa的两阶段提交，但是在代码层面进行人为实现。
核心：针对每个事务操作都要注册一个与之对应的确认和补偿。
- try阶段：针对业务系统做检测
- confirm阶段：确认执行
- cancel阶段：取消执行业务

tcc事务和两阶段提交的处理流程比较相似，不过2pc通常在跨库的DB层面，
tcc本质是个应用层面的2pc，需要通过业务逻辑来实现。

优点：可以让应用自定义数据库操作粒度，从而降低锁冲突，提高吞吐量。
缺点：
	嵌入性强；
	业务每个分支都需要try confirm cancel三个操作，逻辑繁复；
	实现难度大，需要根据网络状态，系统故障不通情况实现不通回滚策略
	为满足数据一致性，cancel和confirm接口还需要实现幂等
![在这里插入图片描述](https://img-blog.csdnimg.cn/20201112103820385.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RvbWF0b0ZJUkVlZ2c=,size_16,color_FFFFFF,t_70#pic_center)

图片我是没看懂 协调服务怎么工作的

参考链接

什么是分布式事务
分布式事务深入