Java面试突击每日十题【Day02】——Zookeeper篇

1. Zookeeper是什么？有哪些特性？
2. Zookeeper有哪几种数据节点？
3. Zookeeper下Server工作状态？
4. Zookeeper常见的应用场景？
5. Zookeeper是如何保证事务的顺序一致性的？
6. Zookeeper有哪几种部署方式，集群最少几台机器，集群的规则是怎样的？若说集群有三台机器，其中一个节点宕机，这时候Zookeeper还能继续使用吗？宕机如何处理？
7. Zookeeper支持动态添加机器吗？
8. 讲讲ZAB协议，ZAB和Paxos算法的区别和联系？
9. Zookeeper初始化是如何进行Leader选举的？
10. 选举Leader后如何进行数据同步的？
    

一、ZooKeeper 是一个开源的分布式协调服务。它是一个为分布式应用提供一致性 服务的软件，分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、 负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和 分布式队列等功能。
ZooKeeper 的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性 能高效、功能稳定的系统提供给用户。
Zookeeper 保证了如下分布式一致性特性：
（1）顺序一致性
（2）原子性
（3）单一视图
（4）可靠性
（5）实时性（最终一致性）
客户端的读请求可以被集群中的任意一台机器处理，如果读请求在节点上注册了 监听器，这个监听器也是由所连接的 zookeeper 机器来处理。对于写请求，这 些请求会同时发给其他 zookeeper 机器并且达成一致后，请求才会返回成功。
因此，随着 zookeeper 的集群机器增多，读请求的吞吐会提高但是写请求的吞 吐会下降。
有序性是 zookeeper 中非常重要的一个特性，所有的更新都是全局有序的，每 个更新都有一个唯一的时间戳，这个时间戳称为 zxid（Zookeeper Transaction Id）。而读请求只会相对于更新有序，也就是读请求的返回结果中 会带有这个zookeeper 最新的 zxid。
二、四种数据节点
（1）PERSISTENT-持久节点 ：除非手动删除，否则节点一直存在于 Zookeeper 上 。
（2）EPHEMERAL-临时节点 ：临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与 zookeeper 连接断开不一定会话失效），那么这个客户端创建的所有临时节点 都会被移除。
（3）PERSISTENT_SEQUENTIAL-持久顺序节点 ：基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维 护的自增整型数字。
（4）EPHEMERAL_SEQUENTIAL-临时顺序节点 ：基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的 自增整型数字。
三、服务器具有四种状态，分别是 LOOKING、FOLLOWING、LEADING、 OBSERVING。
（1） LOOKING：寻 找 Leader 状态。当服务器处于该状态时，它会认为当前集群中没有 Leader，因此需要进入 Leader 选举状态。
（2） FOLLOWING：跟随者状态。表明当前服务器角色是 Follower。
（3）LEADING：领导者状态。表明当前服务器角色是 Leader。
（4）OBSERVING：观察者状态。表明当前服务器角色是 Observer。
四、Zookeeper 是一个典型的发布/订阅模式的分布式数据管理与协调框架，开发人员可以使用它来进行分布式数据的发布和订阅。
通过对 Zookeeper 中丰富的数据节点进行交叉使用，配合 Watcher 事件通知机制，可以非常方便的构建一系列分布式应用中年都会涉及的核心功能，如：
（1） 数据发布/订阅
（2） 负载均衡
（3） 命名服务
（4） 分布式协调/通知
（5） 集群管理
（6） Master 选举
（7） 分布式锁
（8） 分布式队列数据发布/订阅介绍数据发布/订阅系统，即所谓的配置中心，顾名思义就是发布者发布数据供订阅者进行数据订阅。
五、zookeeper 采用了全局递增的事务 Id 来标识，所有的 proposal（提议）都在被提出的时候加上了 zxid，zxid 实际上是一个 64 位的数字，高 32 位是
epoch（ 时期; 纪元; 世; 新时代）用来标识 leader 周期，如果有新的 leader 产生出来，epoch会自增，低 32 位用来递增计数。当新产生 proposal 的时候，会依据数据库的两阶段过程，首先会向其他的 server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。
六、Zookeeper 有三种部署模式：
1. 单机部署：一台集群上运行；
2. 集群部署：多台集群运行；
3. 伪集群部署：一台集群启动多个 Zookeeper 实例运行。
集群规则为 2N+1 台，N>0，即 3 台。可以继续使用，单数服务器只要没超过一半的服务器宕机就可以继续使用。

Zookeeper 本身也是集群，推荐配置不少于 3 个服务器。Zookeeper 自身也要保证当一个节点宕机时，其他节点会继续提供服务。
如果是一个 Follower 宕机，还有 2 台服务器提供访问，因为 Zookeeper 上的数据是有多个副本的，数据并不会丢失；
如果是一个 Leader 宕机，Zookeeper 会选举出新的 Leader。
ZK 集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。
所以，3 个节点的 cluster 可以挂掉 1 个节点(leader 可以得到 2 票>1.5)
2 个节点的 cluster 就不能挂掉任何 1 个节点了(leader 可以得到 1 票<=1) 19. zookeeper 负载均衡和 nginx 负载均衡区别：
zk 的负载均衡是可以调控，nginx 只是能调权重，其他需要可控的都需要自己写插件；但是 nginx 的吞吐量比 zk 大很多，应该说按业务选择用哪种方式。
七、其实就是水平扩容了，Zookeeper 在这方面不太好。两种方式：
全部重启：关闭所有 Zookeeper 服务，修改配置之后启动。不影响之前客户端的会话。
逐个重启：在过半存活即可用的原则下，一台机器重启不影响整个集群对外提供服务。这是比较常用的方式。3.5 版本开始支持动态扩容。
八、相同点：
（1） 两者都存在一个类似于 Leader 进程的角色，由其负责协调多个 Follower 进程的运行
（2） Leader 进程都会等待超过半数的 Follower 做出正确的反馈后，才会将一个提案进行提交
（3） ZAB 协议中，每个 Proposal 中都包含一个 epoch 值来代表当前的
Leader周期，Paxos 中名字为 Ballot 不同点：
ZAB 用来构建高可用的分布式数据主备系统（Zookeeper），Paxos 是用来构建分布式一致性状态机系统。
九、在集群初始化阶段，只有两台以以上的 ZK 启动才会发生leader选举，过程如下：
(1) 每个 Server 发出一个投票。初始选举 ZK1 和 ZK2 都会将自己作为 Leader 服务器来进行投票，每次投票会包含所推举的服务器的(myid, ZXID)，此时 ZK1 的投票为(1, 0)，ZK2 的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。
(2) 收到投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自 LOOKING 状态的服务器。
(3) 处理投票。每个发起投票的服务器需要将别人的投票和自己的投票进行比较，规则如下:
优先检查 ZXID。ZXID 比较大的服务器优先作为 Leader。如果 ZXID 相同，那么就比较 myid。myid 较大的服务器作为Leader服务器。
(4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于 ZK1、ZK2 而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出 ZK2 作为Leader。
(5) 改变服务器状态。一旦确定了 Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为 FOLLOWING，如果是 Leader，就变更为 LEADING。当新的 Zookeeper 节点 ZK3 启动时，发现已经有 Leader 了，不再选举，直接将直接的状态从 LOOKING 改为 FOLLOWING。
十、整个集群完成 Leader 选举之后，Learner（Follower 和 Observer 的统称）回向Leader 服务器进行注册。当 Learner 服务器想 Leader 服务器完成注册后，进入数据同步环节。数据同步流程：（均以消息传递的方式进行）
Learner 向 Learder 注册
数据同步同步确认
Zookeeper 的数据同步通常分为四类：
（1） 直接差异化同步（DIFF 同步）
（2） 先回滚再差异化同步（TRUNC+DIFF 同步）
（3） 仅回滚同步（TRUNC 同步）（4）全量同步（SNAP 同步）
在进行数据同步前，Leader 服务器会完成数据同步初始化： peerLastZxid：
∙ 从 learner 服务器注册时发送的 ACKEPOCH 消息中提取 lastZxid（该Learner 服务器最后处理的 ZXID）
minCommittedLog：
∙ Leader 服务器 Proposal 缓存队列 committedLog 中最小
ZXIDmaxCommittedLog：
∙ Leader 服务器 Proposal 缓存队列 committedLog 中最大 ZXID直接差异化同步（DIFF 同步）
∙ 场景：peerLastZxid 介于 minCommittedLog 和 maxCommittedLog之间先回滚再差异化同步（TRUNC+DIFF 同步）

∙ 场景：当新的 Leader 服务器发现某个 Learner 服务器包含了一条自己没有的事务记录，那么就需要让该 Learner 服务器进行事务回滚–回滚到 Leader服务器上存在的，同时也是最接近于 peerLastZxid 的 ZXID仅回滚同步（TRUNC 同步）
∙ 场景：peerLastZxid 大于 maxCommittedLog 全量同步（SNAP 同步）
∙ 场景一：peerLastZxid 小于 minCommittedLog
∙ 场景二：Leader 服务器上没有 Proposal 缓存队列且 peerLastZxid 不等于 lastProcessZxid