欢迎访问我的blog http://www.codinglemon.cn/
立个flag，8月20日前整理出所有面试常见问题，包括有：
Java基础、JVM、多线程、Spring、Redis、MySQL、Zookeeper、Dubbo、RokectMQ、分布式锁、算法。
10. Zookeeper篇
文章目录
Zookeeper集群：一个领导者(Leader)，多个跟随者(Follower)组成的集群。
他的目标是可以提供高性能、高可用和顺序访问控制的能力，同时也是为了解决分布式环境下数据一致性的问题。
10.1 Zookeeper介绍
10.1.1 集群
首先，Zookeeper集群中有几个关键的概念，Leader、Follower和Observer，Zookeeper中通常只有Leader节点可以写入，Follower和Observer都只是负责读，但是Follower会参与节点的选举和过半写成功，Observer则不会，他只是单纯的提供读取数据的功能。
通常这样设置的话，是为了避免太多的从节点参与过半写的过程，导致影响性能，这样Zookeeper只要使用一个几台机器的小集群就可以实现高性能了，如果要横向扩展的话，只需要增加Observer节点即可。
Zookeeper建议集群节点个数为奇数，只要超过一半的机器能够正常提供服务，那么整个集群都是可用的状态。
10.1.2 数据节点Znode
Zookeeper中数据存储于内存之中，这个数据节点就叫做Znode，他是一个树形结构，比如/a/b/c类似。
而Znode又分为持久节点、临时节点、顺序节点三大类。
持久节点是指只要被创建，除非主动移除，否则都应该一直保存在Zookeeper中。
临时节点不同的是，他的生命周期和客户端Session会话一样，会话失效，那么临时节点就会被移除。
还有就是临时顺序节点和持久顺序节点，除了基本的特性之外，子节点的名称还具有有序性。
10.1.3 会话Session
会话自然就是指Zookeeper客户端和服务端之间的通信，他们使用TCP长连接的方式保持通信，通常，肯定会有心跳检测的机制，同时他可以接受来自服务器的Watch事件通知。
10.1.4 事件监听器Wather
用户可以在指定的节点上注册Wather，这样在事件触发的时候，客户端就会收到来自服务端的通知。
10.1.5 权限控制ACL
Zookeeper使用ACL来进行权限的控制，包含以下5种：
- CREATE，创建子节点权限
- DELETE，删除子节点权限
- READ，获取节点数据和子节点列表权限
- WRITE，更新节点权限
- ADMIN，设置节点ACL权限
所以，Zookeeper通过集群的方式来做到高可用，通过内存数据节点Znode来达到高性能，但是存储的数据量不能太大，通常适用于读多写少的场景。
10.2 Zookeeper的应用场景
-
命名服务Name Service，依赖Zookeeper可以生成全局唯一的节点ID，来对分布式系统中的资源进行管理。
-
分布式协调，这是Zookeeper的核心使用了。利用Wather的监听机制，一个系统的某个节点状态发生改变，另外系统可以得到通知。
-
集群管理，分布式集群中状态的监控和管理，使用Zookeeper来存储。
-
Master选举，利用Zookeeper节点的全局唯一性，同时只有一个客户端能够创建成功的特点，可以作为Master选举使用，创建成功的则作为Master。
-
分布式锁，利用Zookeeper创建临时顺序节点的特性。
10.3 Zookeeper的选举机制
半数机制（paxos协议）
集群中半数以上机器存活，集群可用，所以Zookeeper适合安装奇数台服务器
三个核心选举原则：
（1）Zookeeper集群中只有超过半数以上的服务器启动，集群才能正常工作；
（2）在集群正常工作之前，myid小的服务器给myid大的服务器投票，直到集群正常工作，选出Leader(超过集群机器的半数)；
（3）选出Leader之后，之前的服务器状态由Looking改变为Following，以后的服务器都是Follower。
10.3.1 内部选举步骤(Zab 的四个阶段)
1. 选举阶段 Leader election
节点在一开始都处于选举节点，只要有一个节点得到超过半数节点的票数，它就可以当选准 Leader，只有到达第三个阶段（也就是同步阶段），这个准 Leader 才会成为真正的 Leader。
Zookeeper 规定所有有效的投票都必须在同一个 轮次 中，每个服务器在开始新一轮投票时，都会对自己维护的 logicalClock 进行自增操作。
最大ZXID也就是节点本地的最新事务编号，包含epoch和计数两部分。epoch是纪元的意思，相当于Raft算法选主时候的term，标识当前leader周期，每次选举一个新的Leader服务器后，会生成一个新的epoch。（首先选举 epoch 最大的，如果 epoch 相等，则选 zxid 最大的，若 epoch 和 zxid 都相等，则选择 server id 最大的。 在选举过程中，如果有节点获得超过半数的投票数，则会成为 Leader 节点，反之则重新投票选举。）
所有节点处于Looking状态，各自依次发起投票，投票包含自己的服务器ID和最新事务ID（ZXID）。
如果发现别人的 ZXID比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的 ZXID所属节点。
每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为 Leading。其他节点的状态变为Following。
2. 发现阶段 Discovery
为了防止某些意外情况，比如因网络原因在上一阶段产生多个 Leader的情况。
Leader集思广益，接收所有 Follower发来各自的最新 epoch值。 Leader从中选出最大的 epoch，基于此值加1，生成新的 epoch分发给各个 Follower。
各个 Follower收到全新的 epoch后，返回 ACK给 Leader，带上各自最大的 ZXID和历史事务日志。 Leader选出最大的 ZXID，并更新自身历史日志。
这个阶段的主要目的是发现当前大多数节点接收的最新事务 Proposal，并且准 Leader 生成新的 epoch ，让 Followers 接收，更新它们的 acceptedEpoch。
3. 同步阶段 Synchronization
同步阶段主要是利用 Leader 前一阶段获得的最新 事务Proposal 历史，同步集群中所有的副本。
Leader刚才收集得到的最新历史事务日志，同步给集群中所有的Follower。只有当半数Follower同步成功，这个准Leader才能成为正式的Leader。
4、广播阶段（Broadcast）
到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 Leader 可以进行消息广播。同时，如果有新的节点加入，还需要对新节点进行同步。
10.4 Zookeeper的写数据流程
预提交过程
- 客户端发出写入数据请求给任意Follower。
- Follower把写入数据请求转发给Leader。
- Leader采用二阶段提交方式，先发送Propose广播给Follower。
- Follower接到Propose消息，写入日志成功后，返回ACK消息给Leader。
- Leader接到半数以上ACK消息，返回成功给客户端，并且广播Commit请求给Follower
10.5 Zookeeper监听器原理
- Main进程
- 创建ZK客户端，会创建connet网络连接通信线程，listener监听线程
- 通过connect线程将注册的监听事件发送给Zookeeper服务端
- 将监听事件添加到注册监听器列表
- 监听到有数据或路径变化，将消息发送给listener
- listener线程内部调用process方法
10.6 ZAB协议
Zab协议是为分布式协调服务Zookeeper专门设计的一种 支持崩溃恢复 的 原子广播协议，Zab协议要求每个 Leader 都要经历三个阶段：发现，同步，广播。
1）Zab 协议需要确保那些已经在 Leader 服务器上提交（Commit）的事务最终被所有的服务器提交。
2）Zab 协议需要确保丢弃那些只在 Leader 上被提出而没有被提交的事务。
作用
- 使用一个单一的主进程（Leader）来接收并处理客户端的事务请求（也就是写请求），并采用了Zab的原子广播协议，将服务器数据的状态变更以 事务proposal （事务提议）的形式广播到所有的副本（Follower）进程上去。
- 保证一个全局的变更序列被顺序引用。
- 当主进程出现异常的时候，整个zk集群依旧能正常工作。
在Zab协议中，只要超过半数的Follower服务器进行了正确的反馈后（也就是收到半数以上的Follower的Ack请求），那么 Leader 就会再次向所有的 Follower服务器发送 Commit 消息，要求其将上一个 事务proposal 进行提交。
Zab协议内容 （崩溃恢复 和 消息广播）
通过 Zab 协议（原子广播协议）来保证分布式事务的最终一致性。 在 ZooKeeper 集群中，所有客户端的请求都是写入到 Leader 进程中的，然后，由 Leader 同步到其他节点，称为 Follower。在集群数据同步的过程中，如果出现 Follower 节点崩溃或者 Leader 进程崩溃时，都会通过 Zab 协议来保证数据一致性。
消息广播
Zab协议中 Leader 等待 Follower 的ACK反馈消息是指“只要半数以上的Follower成功反馈即可，不需要收到全部Follower反馈”。
- zookeeper 采用 Zab 协议的核心，就是只要有一台服务器提交了 Proposal，就要确保所有的服务器最终都能正确提交 Proposal。这也是 CAP/BASE 实现最终一致性的一个体现。
- Leader 服务器与每一个 Follower 服务器之间都维护了一个单独的 FIFO 消息队列进行收发消息，使用队列消息可以做到异步解耦。 Leader 和 Follower 之间只需要往队列中发消息即可。如果使用同步的方式会引起阻塞，性能要下降很多。
崩溃恢复
一旦 Leader 服务器出现崩溃或者由于网络原因导致 Leader 服务器失去了与过半 Follower 的联系，那么就会进入崩溃恢复模式。
Zab 协议崩溃恢复要求满足以下两个要求：
- 确保已经被 Leader 提交的事务必须最终被所有的 Follower 服务器提交。
- 确保丢弃已经被 Leader 提出的但是没有被提交的事务。
leader选举
- 新选举出来的 Leader 不能包含未提交的 Proposal 。
- 新选举的 Leader 节点中含有最大的 zxid 。
数据恢复
- 完成 Leader 选举后（新的 Leader 具有最高的zxid），在正式开始工作之前（接收事务请求，然后提出新的 Proposal），Leader 服务器会首先确认事务日志中的所有的 事务是否已经被集群中过半的服务器 Commit。
- Leader 服务器需要确保所有的 Follower 服务器能够接收到每一条事务的 Proposal ，并且能将所有已经提交的事务 Proposal 应用到内存数据中。等到 Follower 将所有尚未同步的事务 Proposal 都从 Leader 服务器上同步过啦并且应用到内存数据中以后，Leader 才会把该 Follower 加入到真正可用的 Follower 列表中。
10.7 Zookeeper 节点宕机如何处理？
Zookeeper 本身也是集群，推荐配置不少于 3 个服务器。Zookeeper 自身也要保证当一个节点宕机时，其他节点会继续提供服务。如果是一个 Follower 宕机，还有 2 台服务器提供访问，因为 Zookeeper 上的数据是有多个副本的，数据并不会丢失；如果是一个 Leader 宕机，Zookeeper 会选举出新的 Leader。ZK 集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在 ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。
10.8 如何实现分布式一致性
利用ZAB协议保证分布式的一致性，然后通过ZAB展开说明zookeeper的选举机制、崩溃恢复机制、数据恢复机制等。
10.9 有可能会出现数据不一致的问题吗？
还是会存在的，我们可以分成3个场景来描述这个问题。
1. 查询不一致
因为Zookeeper是过半成功即代表成功，假设我们有5个节点，如果123节点写入成功，如果这时候请求访问到4或者5节点，那么有可能读取不到数据，因为可能数据还没有同步到4、5节点中，也可以认为这算是数据不一致的问题。
解决方案可以在读取前使用sync命令。
2. leader未发送proposal宕机
这也就是数据同步说过的问题。
leader刚生成一个proposal，还没有来得及发送出去，此时leader宕机，重新选举之后作为follower，但是新的leader没有这个proposal。
这种场景下的日志将会被丢弃。
3. leader发送proposal成功，发送commit前宕机
如果发送proposal成功了，但是在将要发送commit命令前宕机了，如果重新进行选举，还是会选择zxid最大的节点作为leader，因此，这个日志并不会被丢弃，会在选举出leader之后重新同步到其他节点当中。
10.10 如何理解CAP理论？
CAP是一个分布式系统设计的定理，他包含3个部分，并且最多只能同时满足其中两个。
-
Consistency一致性，因为在一个分布式系统中，数据肯定需要在不同的节点之间进行同步，就比如Zookeeper，所以一致性就是指的是数据在不同的节点之间怎样保证一致性，对于纯理论的C而言，默认的规则是忽略掉延迟的，因为如果考虑延迟的话，因为数据同步的过程无论如何都会有延迟的，延迟的过程必然会带来数据的不一致。
-
Availability可用性，这个指的是对于每一个请求，节点总是可以在合理的时间返回合理的响应，比如Zookeeper在进行数据同步时，无法对外提供读写服务，不满足可用性要求。这里常有的一个例子是说Zookeeper选举期间无法提供服务不满足A，这个说法并不准确，因为CAP关注的是数据的读写，选举可以认为不在考虑范围之内。所以，可以认为对于数据的读写，无论响应超时还是返回异常都可以认为是不满足A。
-
Partition-tolerance分区容错性，因为在一个分布式系统当中，很有可能由于部分节点的网络问题导致整个集群之间的网络不连通，所以就产生了网络分区，整个集群的环境被分隔成不同的的子网，所以，一般说网络不可能100%的不产生问题，所以P一定会存在。
为什么只能同时满足CAP中的两个呢？
以A\B两个节点同步数据举例，由于P的存在，那么可能AB同步数据出现问题。
如果选择AP，由于A的数据未能正确同步到B，所以AB数据不一致，无法满足C。
如果选择CP，那么B就不能提供服务，就无法满足A。