zookeeper协议浅析

是一个高可靠、高可用、高性能的分布式一致系统,核心为ZAB协议。

zookeeper一致性协议

zookeeper实现数据一致性的核心是ZAB协议(Zookeeper原子消息广播协议)。该协议需要做到以下几点:

(1)集群在半数以下节点宕机的情况下,能正常对外提供服务;

(2)客户端的写请求全部转交给leader来处理,leader需确保写变更能实时同步给所有follower及observer;

(3)leader宕机或整个集群重启时,需要确保那些已经在leader服务器上提交的事务最终被所有服务器都提交,确保丢弃那些只在leader服务器上被提出的事务,并保证集群能快速恢复到故障前的状态。

zookeeper设计特点

高性能:全部数据内存存储,即存储的数据量是有限的,受限于所在宿主机的内存的大小

高可用:只要可用机器数在一半以上就是可用的。

一致性:ZAB协议保证,事务要么完成,要么未完成,未有中间状态。

ZAB协议与paxos对比

共同点:

leader向所有的followers提议。

leader在收到一定数目的followers的ack之后,才会commit。

提议中包含epoch,类似于paxos的ballot number。

不同点:

一个有状态的机器(zab协议)是用来处理一系列的请求。一个有状态的机器复制系统,是一个clientserver系统,每个状态机器的复制请求都会按照client请求的顺序进行执行。

在主备份系统中(paxos协议),一致性是delta状态的一致性。由主备份产生并发送给followers。

ZAB协议:

协议定义

leader followers:有一个唯一的leader,若干个followers,leader+followers满足奇数个。leader角色负责接受所有的从clients或者从follower以副本形式发过来的变更状态。读请求则在所有的followers与leader之间进行负载均衡。

事务:所有的状态变更由leader广播给所有的followers

e- leader的标志。epoch是一个整数,在一个leader开始领导的时候产生,并且应该比前面的leader的epoch都大

c-leader产生的一个顺序数字,从0开始并且递增。与epoch一起用来标识从client过来的状态变化

F.history-followers的历史队列。用来有顺序的提交过来事务顺序。

ZAB Implementation

clients可以从zk nodes的任何一个server读数据

clients的写状态变更可以发送到任何一个server,这个状态的变更被转发到leader节点。zk 用一个改良的二阶段提交协议将复制的事务发送给followers。当leader收到client的变更请求,leader会产生一个带有sequencenumber以及epoch的事务发送给所有的followers。一个follower将事务添加到历史队列中并发送ack给leader。当leader收到法定个数的ack,就会发送commit请求。一个follower接收COMMIT请求,并提交事务;除非sequencenumber比历史队列中的sequencenumber大?。在提交之前,等待收到所有的比它早的事务。

如果leader崩溃,所有的nodes将拒绝服务,并会执行恢复协议来达成一致状态,选举一个新的leader来广播状态变更。

为了选择leader,node必须获取一定数目nodes的支持。

node的生命周期:每个node在一定时间内会执行协议的迭代。在任何时间点,一个进程可能放弃当前的迭代,并开始一个新的阶段0

ZAB协议生命周期

阶段0-预期leader选举

阶段1-发现

阶段2-同步

阶段3-广播

阶段1 和 2 对于达成一致状态,特别是从崩溃中恢复至关重要

阶段1-发现 在这个阶段,followers对他们预期的leader进行通信,leader 收集followers接收的最近最新的事务信息。这个阶段的目的是在一定树木中发现接受的事务的最新sequence,建立一个新的epoch,让以前的leaders不能提交新的提议。因为一定数目的followers有前面的leader发送的已经接受的所有的变更-那么至少有一个follower在他的历史队列中有所有已经接受的变更,这就意味着新的leader也会拥有他们。

阶段2-同步 同步阶段包含协议的恢复阶段,将在发现阶段更新的历史事务在集群间同步所有的备份。leader与followers进行通信,提议事务。followers确认提议。当leader收到一定数目的acks,leader就会发起一个commit 信息。在那个时候,leader已经建立了,已经是非预期了。

阶段3-广播 如果没有崩溃,集群将会永远在这个阶段,当client发起一个写请求的时候,在集群之间进行广播事务。为了发现失败,zab 在leader与followers之间有周期性的心跳。如果在给定时间内leader未收到一定数目的心跳,它将会放弃他的领导地位,并开始选举阶段0.如果follower未在一定时间内收到心跳,也会发起选举leader。

附录

https://distributedalgorithm.wordpress.com/2015/06/20/architecture-of-zab-zookeeper-atomic-broadcast-protocol/

https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab1.0

https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab+vs.+Paxos

    原文作者:菜鸟小玄
    原文地址: https://www.jianshu.com/p/be24a05f2d38
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞