分布式一致性协议比较(paxos/zab)

目录

1 paxos

1.1 名词解释

1.2 流程

1.2.1 第一阶段:提议(prepare)

1.2.2 第二阶段:成交(accept)

1.2.3 第三阶段:同步(learn) <非必需>

1.3 细节与问题

1.3.1 提案编号生成

1.3.2 活锁(Livelock)

1.3.3 数据同步

2 Zab

2.1 名词解释

2.2 模式

2.2.1 广播模式

2.2.2 恢复模式

2.3 算法描述

2.3.1 阶段一:发现

2.3.2 阶段二:同步

2.3.3 阶段三:广播

2.3.4 总结和个人理解

2.4 leader 选举实现

2.4.1 选票内容

2.4.2 选举流程

 2.5 数据同步

2.5.1 名词解释

2.5.2 同步方式

2.6 对比 paxos

2.6.1 选票生成

2.6.2 日志空洞

2.6.2 幽灵复现


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接

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值