Zookeeper面试题

• 选举机制
• • 第一次启动选举规则：
  • 第二次启动选举规则：
• 生产集群安装多少 zk 合适
• 常用命令
• Paxos算法
• 讲一讲什么是CAP法则？Zookeeper符合了这个法则的哪两个？

半数机制，超过半数的投票通过，即通过

1. 服务器1启动， 发起一次选举。 服务器1投自己一票。 此时服务器1票数一票， 不够半数以上（ 3票） ， 选举无法完成， 服务器1状态保持为 LOOKING
2. 服务器2启动， 再发起一次选举。 服务器1和2分别投自己一票并交换选票信息： 此时服务器1发现服务器2的 myid 比自己目前投票推举的（服务器1）大， 更改选票为推举服务器2。 此时服务器1票数0票， 服务器2票数2票， 没有半数以上结果， 选举无法完成， 服务器1， 2状态保持 LOOKING
3. 服务器3启动， 发起一次选举。 此时服务器1和2都会更改选票为服务器3。 此次投票结果：服务器1为0票， 服务器2为0票， 服务器3为3票。 此时服务器3的票数已经超过半数， 服务器3当选Leader。 服务器1， 2更改状态为 FOLLOWING， 服务器3更改状态为 LEADING
4. 服务器4启动， 发起一次选举。 此时服务器1， 2， 3已经不是LOOKING状态， 不会更改选票信息。 交换选票信息结果：服务器3为3票， 服务器4为1票。 此时服务器4服从多数， 更改选票信息为服务器3， 并更改状态为FOLLOWING
5. 服务器5启动， 同4一样当小弟

投票过半数时， 服务器 id 大的胜出

当 ZooKeeper 集群中的一台服务器出现以下两种情况之一时， 就会开始进入Leader 选举：

• 服务器初始化启动
• 服务器运行期间无法和 Leader 保持连接

而当一台机器进入 Leader 选举流程时，当前集群也可能会处于以下两种状态：

• 集群中本来就已经存在一个 Leader

对于第一种已经存在 Leader 的情况，机器试图去选举 Leader 时，会被告知当前服务器的 Leader 信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可

• 集群中确实不存在Leader

假设ZooKeeper由5台服务器组成， SID分别为1、 2、 3、 4、 5， ZXID分别为8、 8、 8、 7、 7，并且此时SID为3的服务器是Leader。某一时刻，3和5服务器出现故障，因此开始进行Leader选举

SID为1、 2、 4的机器投票情况：

选举Leader规则：

• EPOCH大的直接胜出
• EPOCH相同，事务id大的胜出
• 事务id相同，服务器id大的胜出

安装奇数台

生产经验：

• 10 台服务器： 3 台 zk
• 20 台服务器： 5 台 zk
• 100 台服务器： 11 台 zk
• 200 台服务器： 11 台 zk

服务器台数多：

• 好处，提高可靠性
• 坏处：提高通信延时

查看 znode 节点数据信息

ls

获得节点的值

get

普通创建

create

删除节点

delete

Paxos算法一种基于消息传递且具有高度容错特性的一致性算法。

分布式系统中的节点通信存在两种模型：共享内存（Shared memory）和消息传递（Messages passing）。基于消息传递通信模型的分布式系统，不可避免的会发生以下错误：进程可能会慢、被杀死或者重启，消息可能会延迟、丢失、重复，在基础Paxos场景中，先不考虑可能出现消息篡改即拜占庭错误的情况。Paxos算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致，保证不论发生以上任何异常，都不会破坏决议的一致性

CAP法则：强一致性、高可用性、分区容错性

Zookeeper 符合强一致性、高可用性