Zookeeper原理和业界实践
2019年07月17日

PS:

ZK基础参见另一篇文章:《ZooKeeper简介、基础知识和主要配置》



使用的协议:

ZAB(zookeeper原子广播),为paxos的一种实现。


Zookeeper提供了三种选择策略:

  LeaderElection

  AuthFastLeaderElection

  FastLeaderElection

这里仅介绍默认的算法:FastLeaderElection。


基础概念

  • Sid:服务器id;

  • Zxid:服务器的事务id,数据越新,zxid越大;

  • epoch:逻辑时钟,在服务端是一个自增序列,每次进入下一轮投票后,就会加1;

server状态:

  • Looking(选举状态)

  • Leading(领导者状态,表明当前server是leader)

  • Following(跟随者状态,表明当前server是Follower)

  • Observing(观察者状态、表明当前server是Observer)。

    每个节点启动的时候都是LOOKING状态,如果这个节点参与选举但最后不是leader,则状态是FOLLOWING,如果不参与选举则是OBSERVING,leader的状态是LEADING。


Zookeeper选举原理,参考文章:

https://www.cnblogs.com/yuyijq/p/4116365.html

https://www.cnblogs.com/scuwangjun/p/9063149.html


zk集群关键特性:投票选leader,某节点要能选举获胜,票数必须大于集群数的一半(大于等于m=n/2+1),换句话说,过半存活,集群才可用。

    所以,n=2、3时,m=2,当n=4、5时,m=3。

    假设有3个节点,投票数必须大于等于2,然后挂掉1个,此时,还剩两个,过半,所以能选出leader。

    如果有2个节点,然后挂掉1个,还剩1个,存活不过半,集群无法提供服务。(zk屏蔽了这种情况,要求集群节点总数必须大于等于3)

    为什么?因为选举算法决定的,在代码里面有如下方法:

public boolean containsQuorum(Set<Long> ackSet) {
    return (ackSet.size() > half);
}

    假设有4个节点,投票数必须大于等于3,然后挂掉1个,此时,还剩3个,超过半数存活,且最多能投出3票,故能正常服务。但如果继续挂掉一个,就还剩2个了,就无法提供服务了。

    所以,4个节点的容错数,和3个节点是一样的。

    所以,部署4个节点是浪费,部署3个节点仅仅是为了节约资源。

    同理,如果想容错数为2,用5个节点就行了。

    为什么3个挂掉一个,还剩两个能选举成功?而4个挂掉2个,还剩两个就不能选举成功了?

我猜是和节点的状态有关,当然还和half变量有关(halt=配置的集群节点数/2,换句话说,和初始配置的集群节点数有挂)。

    奇葩问题:如果配置的3个节点,但只启动两个节点,能选举成功吗?如果选举成功之后,再加入第三个节点,会发生什么变化?


Zookeeper观察者:

http://zookeeper.apache.org/doc/r3.5.5/zookeeperObservers.html

https://agapple.iteye.com/blog/1741921


ZK使用总结:

https://www.jianshu.com/p/eec133595c68



Zookeeper存在不稳定原因分析:

https://www.jianshu.com/p/f30ae8e75d6d

阿里巴巴为什么不用 ZooKeeper 做服务发现?:

http://jm.taobao.org/2018/06/13/做服务发现?/

采用zookeeper的EPHEMERAL节点机制实现服务集群的陷阱:

https://yq.aliyun.com/articles/227260


总结:

    在粗粒度分布式锁,分布式选主,主备高可用切换等不需要高TPS 支持的场景下有不可替代的作用,而这些需求往往多集中在大数据、离线任务等相关的业务领域,因为大数据领域,讲究分割数据集,并且大部分时间分任务多进程/线程并行处理这些数据集,但是总是有一些点上需要将这些任务和进程统一协调,这时候就是 ZooKeeper 发挥巨大作用的用武之地。

    但是在交易场景交易链路上,在主业务数据存取,大规模服务发现、大规模健康监测等方面有天然的短板,应该竭力避免在这些场景下引入 ZooKeeper,在阿里巴巴的生产实践中,应用对ZooKeeper申请使用的时候要进行严格的场景、容量、SLA需求的评估。

    所以可以使用 ZooKeeper,但是大数据请向左,而交易则向右,分布式协调向左,服务发现向右。