目录
1 paxos
1.1 名词解释
- Acceptor:接收Proposal(提案),并选出合适提案的人。Acceptor只接收不小于任何已知编号的提案。
- Proposer:提出Proposal(提案)的人。
- Learner:不参与决策,从Proposer/Acceptor学习最新达成一致的提案结果(V)。
- Propose:提案,由编号M和值V组成。M标示这次提案更改批次,V 为同一批次中的数值。
1.2 流程
1.2.1 第一阶段:提议(prepare)
Proposer 提交一个新生成提案(编号 Mn )发送给超过半数的 Acceptor。
Acceptor 接收到提案后只通过大于现有提案版本的提案。未通过提案可以不进行处理;对于通过的提案 Acceptor 会反馈编号小于 Mn 的提案中编号为最大的提案。
1.2.2 第二阶段:成交(accept)
Proposer 若收到半数以上 Acceptor 的反馈结果,Proposer 就会将所有之中最大的那个 Value 作为自己的 Vn。当Acceptor 都返回空时 Vn 为任意数。
Acceptor 接收到了更大的的提案版本的prepare请求就会拒绝这次的提议,否则会通过这个提议。
1.2.3 第三阶段:同步(learn) <非必需>
Proposer在收到多数Acceptor的Accept之后,标志着本次Accept成功,决议形成,将形成的决议发送给所有Learners。
1.3 细节与问题
算法本身是理论可行的,但是他的一些具体实现上还有很多点。
1.3.1 提案编号生成
Proposer 负责提出提案并生成一个提案的编号,那如何保证提案编号和其他提案不冲突呢?如果有多个 Proposer 生成一样的提案同时进行抢占,有可能导致所有 Proposer 都无法达成一致,应该如何解决?
1.3.2 活锁(Livelock)
如上图所示,当有多个 Proposer 时,Proposer内部的竞争会导致无法达成一致。当存在的proposer 数量过多情况会越发严重。
1.3.3 数据同步
严格意义上来说如果只是进行主节点选举就不用考虑数据方面的问题。但如果根据 paxos 进行数据存储,需要解决数据同步问题,防止出现数据空洞现象或者幽灵复现等问题。
2 Zab
2.1 名词解释
- epoch:主进程的周期,每当一个新的 leader 出现后,新 leader 的 epoch 是原有 epoch+1。
- counter:当前 epoch 中执行的事务的计数。每执行一个事务 counter 就会+1。
- zxid:一个64位的编号,高32是epoch,低32位是 counter ,全剧唯一的递增事务id。
- sid:服务器id。取自zk集群配置文件中myid。
2.2 模式
2.2.1 广播模式
正常模式,通过TCP通讯。由leader接