Zookeeper - 简述分布式一致性协议（2pc、3pc、paxos、zab）

分布式一致性协议

• 二阶段提交协议（2pc）
• 三阶段提交协议（3pc）
• paxos
• zab

在分布式系统中，每个机器都可以确定自己进行的事务操作是否成功，但是无法直接了解其他机器的操作结果。因此，当一个分布式事务操作需要保持ACID 特性时，就需要一个“协调者”节点调度其他“参与者”节点来进行分布式事务操作。

二阶段提交（2pc）

提交事务请求 -> 执行事务提交；缺点：同步阻塞（参与者之间阻塞）、单点问题，脑裂（导致数据不一致问题）；主要用于关系型数据库中，解决了分布式事务的原子性问题；

1. 提交事务请求

1. 协调者向参与者发送事务，并询问是否可以执行事务提交操作，等待参与者响应；
2. 参与者执行事务，将操作写入本地事务日志，向协调者发送反馈；

2. 执行事务提交

参与者反馈，全部ACK

1. 协调者向参与者发送Commit；
2. 参与者执行事务提交，释放事务资源，反馈ACK，；
3. 协调者收到反馈完成事务

参与者反馈，存在NO；协调者等待超时

1. 协调者向参与者发送RollBack；
2. 参与者利用undo，进行事务回滚；
3. 参与者事务回滚之后，向协调者发送ACK 反馈；
4. 协调者接收到ACK，完成事务中断；

三阶段提交（3pc）

cancommit -> precommit -> docommit；优缺点：降低了参与者同步阻塞范围，但是又引入了数据不一致性问题（若出现网络分区）、单点问题依然存在；

1. CanCommit

1. 协调者向参与者发送cancommit 请求（包含事务内容），等待参与者反馈；
2. 参与者接收到cancommit 请求之后，反馈ACK或者NO；

2. PreCommit

参与者反馈，全部ACK

1. 协调者向参与者发送precommit 请求，等待反馈；
2. 参与者执行事务，将操作写入本地事务日志，向协调者发送反馈；

参与者反馈，存在NO；协调者等待超时

1. 协调者向参与者发送abort 请求；
2. 参与者无论是接收到abort 请求还是等待超时都会中断事务；

3. DoCommit

参与者反馈，全部ACK

1. 协调者向参与者发送docommit 请求，等待反馈；
2. 参与者执行事务提交，释放事务资源，反馈ACK，；
3. 协调者接收反馈，完成事务提交；

参与者反馈，存在NO；协调者等待超时

1. 协调者向参与者发送abort 请求；
2. 参与者进行事务回滚；
3. 参与者反馈ACK；
4. 协调者接收到ACK，完成事务中断；

paxos 算法

• paxos 基于消息传递并具有高度容错性；
• paxos 算法的核心是，分布式系统如何就某个状态（提案）达成一致；
• paxos 算法假设不存在“拜占庭将军问题”；
• paxos 算法中的角色：proposer、acceptor、learner；

• proposer：发送提案；
• acceptor：裁决提案；只能批准一个提案；过半批准原则；
• learner：学习提案；

1. prepare 阶段（生成提案）

• proposer 提出编号为Mn 的提案，向acceptor 集合发送prepare 请求；
• acceptor 反馈；

• 保证不再接收编号小于Mn 的提案；
• 返回已经批准的，编号最大的提案的Value；
• 若Mn 小于已经批准的最大编号，则忽略Mn；（优化）

• proposer 收到过半响应，则发送accept 请求（Mn，Vn）给acceptor 集合；Vn 是接收回的最大编号提案的Value；若无Value 可选（acceptor 都未接收提案），Vn 可为任意值；

2. accept 阶段（批准提案）

acceptor 接收到accept 请求之后，只要Mn 不小于已接受提案最大的编号，则批准提案；

learner 获取提案（学习策略）

1. 一旦提案被批准（过半），则发送给所有learner；
2. 提案批准，则发送给一个learner，该learner再发送给其他learner；
3. 提案批准，则发送给一个learner集合，该learner集合再发送给其他learner；

优化

问题：proposer1 与 proposer2 两者陷入死循环；

解决：选出主proposer，只要主proposer 和 过半acceptor 能保持正常，那么但凡主proposer 能提出一个编号更高的提案，这个提案最终将会批准；

应用

zab 协议