《从Paxos到ZooKeeper》第二章总结一:2PC和3PC

第二章:一致性协议

最著名:二阶段提交协议2PC;三阶段提交协议;Paxos算法

  • 2PC和3PC的核心思想:
    每一个机器节点无法直接获取其他分布式节点的操作结果,因此需要引入一个被称为”协调者“的组件来统一调度所有分布式节点的执行逻辑;
    被调度的分布式节点则被称为”参与者“;
    协调者负责调度参与者的行为,并最终决定这些参与者是否要把事务真正进行提交

2.1 2PC(Two-Phase-Commit)

作用:保持原子性和一致性

场景:绝大部分的关系型数据库

协议分为两个阶段来进行处理

2.1.2 阶段一:提交事务请求(投票阶段)

即开始执行事务操作

1.事务询问:协调者向所有参与者发起询问,是否可以执行事务提交操作,并等待参与者们的响应
2.执行事务:参与者们执行事务操作,并将Undo和Redo信息写入事务日志
3.各参与者向协调者反馈事务询问的响应:若成功执行,则反馈给协调者yes;若没有则no

2.1.3 阶段二:执行事务提交(执行阶段)

此阶段的协调者会根据参与者们的反馈情况来决定最终是否可以进行事务提交操作

  • 若反馈为yes:执行事务提交,即提交事务

1.协调者向参与者们发送提交请求
2.参与者们进行事务提交
3.参与者们完成事务提交后,反馈事务提交结果Ack
4.协调者收到所有Ack反馈后,完成事务

  • 若反馈为no:中断事务

1.协调者向参与者们发送回滚请求
2.参与者们进行事务回滚
3.参与者们完成事务回滚后,反馈事务回滚结果Ack
4.协调者收到所有Ack反馈后,完成回滚

2.1.4 总结

核心是对每个事务都采用先尝试后提交的处理方式,可以看作是一个强一致性的算法

总流程如下图:
在这里插入图片描述

2.1.5 优缺点

优点:原理简单、实现方便

缺点:同步阻塞、单点问题、脑裂、太过保守
在这里插入图片描述

2.2 3PC

在2PC的基础了,改进了其缺点,提出了3PC

其将2PC的阶段一的提交事务请求再分为两个阶段:事务询问和事务执行拆开,这样就形成了CanCommit、PreCommit、doCommit三阶段组成的事务处理协议,总流程如图所示:
在这里插入图片描述

下面分三阶段依次讨论

2.2.1 阶段一:CanCommit

在这里插入图片描述
即事务询问,事务操作是否可以进行

2.2.2 阶段二:preCommit

协调者会根据参与者们的反馈情况来决定是否可以进行事务的preCommit操作,正常情况下有两种可能

反馈都是yes:执行事务预提交,即开始执行事务操作
在这里插入图片描述
反馈有一个为no或超时:中断事务
在这里插入图片描述

2.2.3 阶段三:doCommit

该阶段执行真正的事务提交,会存在如下两种情况:

执行提交:即提交事务

在这里插入图片描述
中断事务:反馈为no或超时

在这里插入图片描述
也可能存在如下两种故障:
在这里插入图片描述
一旦出现两种情况之一,最终都会导致参与者无法及时接收到来自协调者的doCommit或abort请求
针对这样的异常情况,参与者们会在等待超时之后,继续进行事务提交

2.2.4 优缺点

优点:拆分2PC的阶段一的操作,即把事务询问和事务执行拆开,这样操作的粒度就会变小,这样等待响应时,就不用事务询问和事务执行一起执行完后等待,而是分开等待,降低了阻塞范围
在这里插入图片描述
缺点:即出现上述的故障
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/qq_41594698/article/details/94055738