阿里云-云小站(无限量代金券发放中)
【腾讯云】云服务器、云数据库、COS、CDN、短信等热卖云产品特惠抢购

ZooKeeper之ZAB协议

143次阅读
没有评论

共计 4737 个字符,预计需要花费 12 分钟才能阅读完成。

ZooKeeper 为高可用的一致性协调框架,自然的 ZooKeeper 也有着一致性算法的实现,ZooKeeper 使用的是 ZAB 协议作为数据一致性的算法,ZAB(ZooKeeper Atomic Broadcast)全称为:原子消息广播协议;ZAB 可以说是在 Paxos 算法基础上进行了扩展改造而来的,ZAB 协议设计了支持崩溃恢复,ZooKeeper 使用单一主进程 Leader 用于处理客户端所有事务请求,采用 ZAB 协议将服务器数状态以事务形式广播到所有 Follower 上;由于事务间可能存在着依赖关系,ZAB 协议保证 Leader 广播的变更序列被顺序的处理,:一个状态被处理那么它所依赖的状态也已经提前被处理;ZAB 协议支持的崩溃恢复可以保证在 Leader 进程崩溃的时候可以重新选出 Leader 并且保证数据的完整性;
在 ZooKeeper 中所有的事务请求都由一个主服务器也就是 Leader 来处理,其他服务器为 Follower,Leader 将客户端的事务请求转换为事务 Proposal,并且将 Proposal 分发给集群中其他所有的 Follower,然后 Leader 等待 Follwer 反馈,当有 过半数(>=N/2+1)的 Follower 反馈信息后,Leader 将再次向集群内 Follower 广播 Commit 信息,Commit 为将之前的 Proposal 提交;

协议状态

ZAB 协议中存在着三种状态,每个节点都属于以下三种中的一种:
1. Looking:系统刚启动时或者 Leader 崩溃后正处于选举状态
2. Following:Follower 节点所处的状态,Follower 与 Leader 处于数据同步阶段;
3. Leading:Leader 所处状态,当前集群中有一个 Leader 为主进程;

ZooKeeper 启动时所有节点初始状态为 Looking,这时集群会尝试选举出一个 Leader 节点,选举出的 Leader 节点切换为 Leading 状态;当节点发现集群中已经选举出 Leader 则该节点会切换到 Following 状态,然后和 Leader 节点保持同步;当 Follower 节点与 Leader 失去联系时 Follower 节点则会切换到 Looking 状态,开始新一轮选举;在 ZooKeeper 的整个生命周期中每个节点都会在 Looking、Following、Leading 状态间不断转换;

ZooKeeper 之 ZAB 协议

状态切换图

选举出 Leader 节点后 ZAB 进入原子广播阶段,这时 Leader 为和自己同步的每个节点 Follower 创建一个操作序列,一个时期一个 Follower 只能和一个 Leader 保持同步,Leader 节点与 Follower 节点使用心跳检测来感知对方的存在;当 Leader 节点在超时时间内收到来自 Follower 的心跳检测那 Follower 节点会一直与该节点保持连接;若超时时间内 Leader 没有接收到来自过半 Follower 节点的心跳检测或 TCP 连接断开,那 Leader 会结束当前周期的领导,切换到 Looking 状态,所有 Follower 节点也会放弃该 Leader 节点切换到 Looking 状态,然后开始新一轮选举;

阶段

ZAB 协议定义了 选举(election)、发现(discovery)、同步(sync)、广播 (Broadcast) 四个阶段;ZAB 选举(election)时当 Follower 存在 ZXID(事务 ID)时判断所有 Follower 节点的事务日志,只有 lastZXID 的节点才有资格成为 Leader,这种情况下选举出来的 Leader 总有最新的事务日志,基于这个原因所以 ZooKeeper 实现的时候把 发现(discovery)与同步(sync)合并为恢复(recovery)阶段;
1. Election:在 Looking 状态中选举出 Leader 节点,Leader 的 lastZXID 总是最新的;
2. Discovery:Follower 节点向准 Leader 推送 FOllOWERINFO,该信息中包含了上一周期的 epoch,接受准 Leader 的 NEWLEADER 指令,检查 newEpoch 有效性,准 Leader 要确保 Follower 的 epoch 与 ZXID 小于或等于自身的;
3. sync:将 Follower 与 Leader 的数据进行同步,由 Leader 发起同步指令,最总保持集群数据的一致性;
4. Broadcast:Leader 广播 Proposal 与 Commit,Follower 接受 Proposal 与 Commit;
5. Recovery:在 Election 阶段选举出 Leader 后本阶段主要工作就是进行数据的同步,使 Leader 具有 highestZXID,集群保持数据的一致性;

选举(Election)
election 阶段必须确保选出的 Leader 具有 highestZXID,否则在 Recovery 阶段没法保证数据的一致性,Recovery 阶段 Leader 要求 Follower 向自己同步数据没有 Follower 要求 Leader 保持数据同步,所有选举出来的 Leader 要具有最新的 ZXID;
在选举的过程中会对每个 Follower 节点的 ZXID 进行对比只有 highestZXID 的 Follower 才可能当选 Leader;
选举流程:
1. 每个 Follower 都向其他节点发送选自身为 Leader 的 Vote 投票请求,等待回复;
2. Follower 接受到的 Vote 如果比自身的大(ZXID 更新)时则投票,并更新自身的 Vote,否则拒绝投票;
3. 每个 Follower 中维护着一个投票记录表,当某个节点收到过半的投票时,结束投票并把该 Follower 选为 Leader,投票结束;

ZAB 协议中使用 ZXID 作为事务编号,ZXID 为 64 位数字,低 32 位为一个递增的计数器,每一个客户端的一个事务请求时 Leader 产生新的事务后该计数器都会加 1,高 32 位为 Leader 周期 epoch 编号,当新选举出一个 Leader 节点时 Leader 会取出本地日志中最大事务 Proposal 的 ZXID 解析出对应的 epoch 把该值加 1 作为新的 epoch,将低 32 位从 0 开始生成新的 ZXID;ZAB 使用 epoch 来区分不同的 Leader 周期;

恢复(Recovery)
在 election 阶段选举出来的 Leader 已经具有最新的 ZXID,所有本阶段的主要工作是根据 Leader 的事务日志对 Follower 节点数据进行更新;
Leader:Leader 生成新的 ZXID 与 epoch,接收 Follower 发送过来的 FOllOWERINFO(含有当前节点的 LastZXID)然后往 Follower 发送 NEWLEADER;Leader 根据 Follower 发送过来的 LastZXID 根据数据更新策略向 Follower 发送更新指令;
同步策略:
1. SNAP:如果 Follower 数据太老,Leader 将发送快照 SNAP 指令给 Follower 同步数据;
2. DIFF:Leader 发送从 Follolwer.lastZXID 到 Leader.lastZXID 议案的 DIFF 指令给 Follower 同步数据;
3. TRUNC:当 Follower.lastZXID 比 Leader.lastZXID 大时,Leader 发送从 Leader.lastZXID 到 Follower.lastZXID 的 TRUNC 指令让 Follower 丢弃该段数据;
Follower:往 Leader 发送 FOLLOERINFO 指令,Leader 拒绝就转到 Election 阶段;接收 Leader 的 NEWLEADER 指令,如果该指令中 epoch 比当前 Follower 的 epoch 小那么 Follower 转到 Election 阶段;Follower 还有主要工作是接收 SNAP/DIFF/TRUNC 指令同步数据与 ZXID,同步成功后回复 ACKNETLEADER,然后进入下一阶段;Follower 将所有事务都同步完成后 Leader 会把该节点添加到可用 Follower 列表中;
SNAP 与 DIFF 用于保证集群中 Follower 节点已经 Committed 的数据的一致性,TRUNC 用于抛弃已经被处理但是没有 Committed 的数据;

广播(Broadcast)
客户端提交事务请求时 Leader 节点为每一个请求生成一个事务 Proposal,将其发送给集群中所有的 Follower 节点,收到过半 Follower 的反馈后开始对事务进行提交,ZAB 协议使用了原子广播协议;在 ZAB 协议中只需要得到过半的 Follower 节点反馈 Ack 就可以对事务进行提交,这也导致了 Leader 几点崩溃后可能会出现数据不一致的情况,ZAB 使用了崩溃恢复来处理数字不一致问题;消息广播使用了 TCP 协议进行通讯所有保证了接受和发送事务的顺序性。广播消息时 Leader 节点为每个事务 Proposal 分配一个全局递增的 ZXID(事务 ID),每个事务 Proposal 都按照 ZXID 顺序来处理;
Leader 节点为每一个 Follower 节点分配一个队列按事务 ZXID 顺序放入到队列中,且根据队列的规则 FIFO 来进行事务的发送。Follower 节点收到事务 Proposal 后会将该事务以事务日志方式写入到本地磁盘中,成功后反馈 Ack 消息给 Leader 节点,Leader 在接收到过半 Follower 节点的 Ack 反馈后就会进行事务的提交,以此同时向所有的 Follower 节点广播 Commit 消息,Follower 节点收到 Commit 后开始对事务进行提交;

Ubuntu 14.04 安装分布式存储 Sheepdog+ZooKeeper  http://www.linuxidc.com/Linux/2014-12/110352.htm

CentOS 6 安装 sheepdog 虚拟机分布式储存  http://www.linuxidc.com/Linux/2013-08/89109.htm

ZooKeeper 集群配置 http://www.linuxidc.com/Linux/2013-06/86348.htm

使用 ZooKeeper 实现分布式共享锁 http://www.linuxidc.com/Linux/2013-06/85550.htm

分布式服务框架 ZooKeeper — 管理分布式环境中的数据 http://www.linuxidc.com/Linux/2013-06/85549.htm

ZooKeeper 集群环境搭建实践 http://www.linuxidc.com/Linux/2013-04/83562.htm

ZooKeeper 服务器集群环境配置实测 http://www.linuxidc.com/Linux/2013-04/83559.htm

ZooKeeper 集群安装 http://www.linuxidc.com/Linux/2012-10/72906.htm

Zookeeper3.4.6 的安装 http://www.linuxidc.com/Linux/2015-05/117697.htm

参考资料:
http://web.stanford.edu/class/cs347/reading/zab.pdf
http://www.tcs.hut.fi/Studies/T-79.5001/reports/2012-deSouzaMedeiros.pdf

本文永久更新链接地址:http://www.linuxidc.com/Linux/2016-03/129508.htm

正文完
星哥说事-微信公众号
post-qrcode
 
星锅
版权声明:本站原创文章,由 星锅 2022-01-21发表,共计4737字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
【腾讯云】推广者专属福利,新客户无门槛领取总价值高达2860元代金券,每种代金券限量500张,先到先得。
阿里云-最新活动爆款每日限量供应
评论(没有评论)
验证码
【腾讯云】云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中