传统分布式事务
分类:
文章
•
2024-05-14 09:05:10
简介
- 传统分布式事务遵循ACID，牺牲系统可用性追求获取强一致。
两阶段提交协议
- 一个协调者（事务管理器），多个参与者（资源管理器）。
准备阶段
- 协调者询问是否可以提交。
- 参与者锁住资源，开始事务操作，写undo和redo，不提交。
- 参与者响应，如果执行成功，返回就绪，如果失败，返回未准备。
执行阶段
- 所有参与者就绪时，进行提交。
- 有一个参与者未准备或超时，回滚。
提交
- 协调者发出正式提交请求。
- 参与者提交本地事务，释放资源。
- 参与者响应提交完成。
- 协调者收到所有参与者的完成后，完成事务。
回滚
- 协调者发出回滚请求。
- 参与者用undo回滚事务，释放资源。
- 参与者响应回滚完成。
- 协调者收到所有参与者回滚后，取消事务。
优化
-
最末参与者优化（LPO，Last Participant Optimization）。最后一个参与者准备阶段和执行阶段合并成一个阶段。
问题
-
同步阻塞。执行过程中，锁住资源，吞吐量低。
-
单点问题。第二阶段协调者故障，参与者事务一直阻塞。
-
数据不一致。第二阶段协调者发出提交，但是部分参与者未执行或者执行失败。
-
二阶段固有问题：协调者发出commit后宕机，而且唯一收到的参与者也宕机，即使新选举出协调者事务的提交状态也是不确定的。
三阶段提交协议
- 相对两阶段的优化点：
-
超时机制。协调者超时->协调者参与者超时。
-
准备阶段一分为二。增加不锁资源的校验阶段。
CanCommit
- 协调者同步发送CanCommit请求。
- 参与者预估状态，可以执行事务返回Yes，不可以返回No，不锁定资源。
PreCommit
- 所有参与者返回Yes，进入准备阶段。
- 有一个参与者返回No或者超时，中断事务。
准备
- 协调者发出PreCommit请求。
- 参与者锁住资源，开始事务操作，写undo和redo，不提交。
- 参与者响应，如果执行成功，返回就绪，如果失败，返回未准备。
中断
- 协调者发出Abort请求。
- 参与者收到后中断事务，或者等待PreCommit超时后中断事务。
DoCommit
- 所有参与者就绪时，进行提交。
- 有一个参与者未准备或超时，回滚。
提交
- 协调者发出正式提交请求。
- 参与者提交本地事务，释放资源。
- 参与者响应提交完成。(如果等待doCommit请求超时，也进行提交）
- 协调者收到所有参与者的完成后，完成事务。
回滚
- 协调者发出回滚请求。
- 参与者用undo回滚事务，释放资源。
- 参与者响应回滚完成。
- 协调者收到所有参与者回滚后，取消事务。
解决两阶段问题
-
同步阻塞解决。canCommit阶段不锁资源。
-
单点解决。提交阶段协调者故障，参与者默认提交。
-
数据不一致存在。doCommit阶段协调者发出回滚，部分参与者由于网络超时未收到，执行commit，出现不一致。解决需要Paxos算法。
-
二阶段固有问题解决：协调者发出commit后宕机，而且唯一收到的参与者也宕机,事务默认提交。
标准事务模型
- X/Open事务模型，是基于两阶段协议的标准系统参考模型。如mysql提供了一种实现。
- TX接口：应用向协调者（事务管理器）发起、提交、回滚事务。
- XA接口：事务管理器将参与者（资源管理器）加入事务，控制两阶段提交。
参考
