死磕Zookeeper系列-2-2PC与3PC
大纲
- 2PC
1.1 二阶段提交可以概括为：
1.2 二阶段分为：投票阶段和执行阶段。
第一阶段： 投票阶段
第二阶段： 执行阶段
1.3 缺点： - 3PC
2.1 三阶段分为：can_commit、pre_commit、do_commit
第一阶段：can_commit
第二阶段：pre_commit
第三阶段：do_commit
2.2 总结：
为了解决分布式一致性问题，前人在性能和数据一致性的反反复复权衡过程中总结了许多典型的协议和算法。其中比较著名的有二阶提交协议（2 Phase Commitment Protocol），三阶提交协议（3 Phase Commitment Protocol）。
为保证事务处理的ACID特性，需要引入“协调者”、“参与者”;
- 协调者：负责调度者的行为，并最终决定这些参与者是否要把事务真正提交.
- 参与者：分布式节点.
1. 2PC
1.1 二阶段提交可以概括为：
- `参与者`将操作结果通知给`协调者`，`协调者`根据`所有参与者`的反馈情况决定`各参与者`是否要**提交操作还是中止操作**.
- 二阶段提交解决的是**分布式数据库强一致性问题**.
1.2 二阶段分为：投票阶段和执行阶段。
第一阶段： 投票阶段
1、协调者向所有参与者发送事务执行请求.
2、参与者在收到请求后，执行事务，但不提交，记录事务日志.
3、参与者将事务执行结果反馈给协调者,并同步阻塞.
第二阶段： 执行阶段
对于第一阶段的询盘，参与者会返回一下三种情况：
① 所有参与者都成功执行事务的.
//针对①，第二阶段:协调者向参与者发送commit通知，参与者执行commit操作，释放占有资源，向协调者返回commit结果.
针对①
② 一个或多个参与者执行失败.
③ 协调者等待超时.
//针对②③,第二阶段：协调者向参与者发送rollback通知，参与者指向rollback操作，释放占有资源，向协调者返回rollback结果.
针对②③
1.3 缺点：
3.1 单点问题：
协调者一旦宕机，所有参与者都处于阻塞状态，会导致整个集群不可用;
3.2 同步阻塞：
所有参与者在等待协调者命令之间都处于阻塞状态，无法处理其他操作，效率低下;
3.3 数据不一致：
在执行阶段，由于网络原因，可能会出现一部分执行者执行了commit操作，而其余的没有收到通知一直处理等待状态，这样都导致了数据不一致;
2. 3PC
2.1 三阶段分为：can_commit、pre_commit、do_commit
第一阶段：can_commit
向所有参与者发送can_commit请求，询问参与者是否可以执行事务，并使参与者进入预备状态.
第二阶段：pre_commit
第二阶段会根据第一阶段的轮盘结果，做如下操作：
①、所有参与者都返回确定信息.
//针对①，第二阶段：协调者向所有参与者发送事务执行通知.参与者在收到请求后，执行事务，但不其提交.
②、一个或者多个参与者返回否定信息.
③、协调者等待超时.
//针对②③，第二阶段：协调者向参与者发送abort通知,请求退出预备状态.参与者在收到abort通知后，中断事务.
针对②③
第三阶段：do_commit
如果第二阶段没有中断，第三阶段会根据事务执行的状态，做如下操作：
①、所有参与者都执行事务成功.
//针对①，第三阶段：协调者向参与者发送commit通知，参与者执行commit操作，释放占有资源，向协调者返回commit结果.。
针对①
②、一个或者多个参与者执行事务失败.
③、协调者等待超时.
//针对②③，第三阶段：调者向参与者发送rollback通知，参与者指向rollback操作，释放占有资源，向协调者返回rollback结果.
针对②③
2.2 总结：
相对于两阶段来说，虽然降低了同步阻塞,但是无法避免数据一致性;
同名博客：https://www.zybuluo.com/yulongsun/note/1011394
人总要为自己走出第一步. ---2018.1.8
