发布网友
发布时间：2023-02-13 15:17
共1个回答
热心网友
时间：2023-09-11 05:34
两阶段提交协议为了保证分布在不同节点上的分布式事务的一致性，我们需要引入一个协调者来管理所有的节点，负责各个本地资源的提交和回滚，并确保这些节点正确提交操作结果，若提交失败则放弃事务。
XA 是一个分布式事务协议，规定了事务管理器和资源管理器接口。因此，XA 协议可以分为两部分，即事务管理器和本地资源管理器。
基于 XA 协议的二阶段提交方法中，二阶段提交协议（The two-phase commit protocol，2PC），用于保证分布式系统中事务提交时的数据一致性，是 XA 在全局事务中用于协调多个资源的机制。
分为投票和提交两个阶段。
投票为第一阶段:
提为第二阶段：
协调者会根据所有参与者返回的信息向参与者发送 DoCommit 或 DoAbort 指令
同步阻塞问题：二阶段提交算法在执行过程中，所有参与节点都是事务阻塞型的。也就是说，当本地资源管理器占有临界资源时，其他资源管理器如果要访问同一临界资源，会处于阻塞状态。
协调者单点故障导致参与者长期阻塞问题：基于 XA 的二阶段提交算法类似于集中式算法，一旦事务管理器发生故障，整个系统都处于停滞状态。尤其是在提交阶段，一旦事务管理器发生故障，资源管理器会由于等待管理器的消息，而一直锁定事务资源，导致整个系统被阻塞。
数据不一致问题：在提交阶段，当协调者向参与者发送 DoCommit 请求之后，如果发生了局部网络异常，或者在发送提交请求的过程中协调者发生了故障，就会导致只有一部分参与者接收到了提交请求并执行提交操作，但其他未接到提交请求的那部分参与者则无法执行事务提交。于是整个分布式系统便出现了数据不一致的问题。
二阶段无法解决的问题：协调者再发出DoCommit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
三阶段提交协议（Three-phase commit protocol，3PC），是对二阶段提交（2PC）的改进。为了解决两阶段提交的同步阻塞和数据不一致问题，三阶段提交引入了超时机制和准备阶段。
超时机制
同时在协调者和参与者中引入超时机制。如果协调者或参与者在规定的时间内没有接收到来自其他节点的响应，就会根据当前的状态选择提交或者终止整个事务。
准备阶段
在第一阶段和第二阶段中间引入了一个准备阶段，也就是在提交阶段之前，加入了一个预提交阶段。在预提交阶段排除一些不一致的情况，保证在最后提交之前各参与节点的状态是一致的。
CanCommit 阶段
协调者向参与者发送请求操作（CanCommit 请求），询问参与者是否可以执行事务提交操作，然后等待参与者的响应；参与者收到 CanCommit 请求之后，回复 Yes，表示可以顺利执行事务；否则回复 No。（我个人理解类似做TCC中Try操作）
PreCommit 阶段
协调者根据参与者的回复情况，来决定是否可以进行 PreCommit 操作 或 中断事务。
如果所有参与者回复的都是“Yes”，那么协调者就会执行事务的预执行：
如果任何一个参与者向协调者发送了“No”消息，或者等待超时之后，协调者都没有收到参与者的响应，就执行中断事务的操作：
DoCommit 阶段
协调者根据参与者的回复情况，来决定是否可以进行 DoCommit 操作 或 中断事务。
如果所有参与者回复的都是“Yes”，那么协调者就会执行事务的提交：
如果任何一个参与者向协调者发送了“No”消息，或者协调者等待超时之后，协调者都没有收到参与者的响应，就执行中断事务的操作：
当参与者PreCommit 阶段向协调者发送 Ack 消息后，如果长时间没有得到协调者的响应，在默认情况下，参与者会自动将超时的事务进行提交，不会像两阶段提交那样被阻塞住
由于存在超时机制，即使协调者发生故障，参与者无法及时收到来自协调者的信息之后，他会默认执行commit。避免参与者长期阻塞。
3PC会在2阶段到3阶段间阻塞，2PC会在1阶段到2阶段整个事务过程中阻塞，因而总体来说3PC并不能不阻塞，只是最大限度减少了阻塞的时间。同时安装5.2也能够解决协调者单点故障导致参与者长期阻塞的问题
3PC和2PC都无法解决数据一致的问题，不过3PC存在超时会通过超时保证协调者和参与者在提交阶段无法通信过程中最终一致，而不需人工介入。
Copyright © 2019-2022 51dongshi.com 版权所有
违法及侵权请联系：TEL:177 7030 7066 E-MAIL:11247931@qq.com 本站由北京市万商天勤律师事务所王兴未律师提供法律服务
