Paxos
- 分布式一致性算法
角色
- 提议者（Proposer）
接收客户端写请求，发起提案
- 接受者（Acceptor）
集群中所有节点包括提议者节点一起参与共同协商
- 学习者（Learner）
被告知投票的结果，接受达成共识的值，存储保存，不参与投票的 过程。一般来说，学习者是数据备份节点，
比如“Master-Slave”模型中的 Slave，被 动地接受数据，容灾备份。
场景理解
我们假设客户端 1 的提案编号为 1，客户端 2 的提案编号为 5，并假设节点 A、B 先收到 来自客户端 1 的准备请求，节点 C 先收到来自客户端 2 的准备请求。
-
准备（Prepare）阶段
-
remark
1：提案阶段不准备值
2：任一节点响应某一提案之后，不会再响应小与这一提案编号的请求
- 接受（Accept）阶段
个人理解：后者优先前者，多数服从少数
ZAB
- zookeeper主要是根据ZAB协议是实现分布式系统数据一致性
角色
- leader
整个zookeeper集群中只有一个节点即Leader将客户端的写操作转化为事物(或提议proposal)
- follower
leader服务器将客户端的写操作数据同步到所有的follower节点中
ZAB协议的两种模式
消息广播模式
ZAB协议中Leader等待follower的ACK反馈是指”只要半数以上的follower成功反馈即可，不需要收到全部follower反馈”
- 流程描述
- 客户端发起一个写操作请求
- Leader服务器将客户端的request请求转化为事物proposql提案，同时为每个proposal分配一个全局唯一的ID，即ZXID。
- leader服务器与每个follower之间都有一个队列，leader将消息发送到该队列
- follower机器从队列中取出消息处理完(写入本地事物日志中)毕后，向leader服务器发送ACK确认。
- leader服务器收到半数以上的follower的ACK后，即认为可以发送commit
- leader向所有的follower服务器发送commit消息。
崩溃恢复
- 场景
leader服务器发生崩溃，则zab协议要求zookeeper集群进行崩溃恢复和leader服务器选举。
- ZAB协议崩溃恢复前提