分布式事务 06 三阶段提交与刚性事务的缺陷

两阶段事务宕机分析

协调者宕机

1. 一阶段宕机：
   • 情景：所有参与者无法收到协调者二阶段的commit或rollback,会一直阻塞，本地事务无法结束
   • 方案：参与者统一rollback(未进入二阶段，参与者都不会受到提交或者回滚命令，当前事务无法继续提交，只能回滚)
2. 二阶段宕机：
   部分参与者无法收到Commit,rollback。这部分没有受到命令的参与者会一直阻塞

参与者宕机

1. 一阶段宕机：
   • 情景：协调者一直等待参与者响应，其他参与者阻塞，全局事务无法结束
   • 方案：参与者统一rollback(未进入二阶段，参与者都不会受到提交或者回滚命令，当前事务无法继续提交，只能回滚)
2. 二阶段宕机：
   协调者发起Commit,某参与者宕机，已经Commit的数据库已经修改成功，宕机的库不成功，导致数据不一致了

网络闪断（脑裂）问题

1. 一阶段闪断：
   • 情景：部分参与者进入阻塞，全局事务无法结束
   • 方案：所有参与者统一rollback，
2. 二阶段闪断：部分参与者Commit，部分未Commit,数据不一致

三阶段事务提交

与两阶段提交的对比

2个改进点

1. 同时为协调者和参与者增加超时机制
2. 在原二阶段提交插入PreCommit阶段，以此保证最后提交阶段之前，各个参与节点状态一致

三阶段提交阶段

1. 询问CanCommit阶段：同2pc的准备阶段，发送cancommit问询，可以提交yes,不可以返回no
2. 锁资源PreparedCommit阶段：一阶段都返回ok，进入preparedcommit阶段，协调者向所有参与者发送prepared，等待所有参与者返回ack。如果都返回ack，进入docommit,有一个没返回ack，就fallback
3. 真正提交DoCommit阶段：协调所有参与者发送docommit所有参与者都提交事务

三阶段提交的单点故障与脑裂问题

1. 第一二阶段出现参与者或者网络脑裂问题?
   • 解决方案：同2pc，所有参与者统一rollback。
2. 第三阶段出现参与者或者协调者故障或网络脑裂问题？
   • 统一提交，前面一二都ok，系统有很大信心成功提交

结论

说白了就多一次校验，“试试”，无法彻底解决单点故障或者网络脑裂，治标不治本，不能彻底解决

刚性事务的最大致命性问题

性能问题：锁住事务时间太长，参与者不能提交事务，要等待其他参与者都Ok，才能一起提交；而且阶段太多，性能必然差。

烤面筋

1. 给我说说2阶段？
2. 给我说说3阶段？和2阶段区别？
3. 缺点?画图说说？

分布式事务06 三阶段提交与刚性事务的缺陷

原文：https://www.cnblogs.com/pipicai96/p/13735497.html