为了保证效率和质量，每篇文章发布6个知识点，由简单及难，我们开始zookeeper：
友情提示：本专栏涉及大数据面试题及相关知识点不同于大多数的网络复制文，是博主精心准备和总结的最新的面试及知识点，喜欢就订阅噢，后续还会开展hdfs源码解析，spark源码解析栏目，欢迎关注博客，大家一起学习！
专栏：点击打开链接
博客：点击打开链接
1）zookeeper的本质是什么？它解决了哪些问题？
ZooKeeper 本质上是一个为分布式应用提供一致性服务的软件。
它解决了下列问题：
1. 分布式系统的一致性问题
2. 分布式系统的容灾容错
3. 分布式系统的执行顺序问题
4. 分布式系统的事务性问题
2）简单介绍一下ZooKeeper的系统架构？
需要清楚的几个概念：
1. 领导者(Leader)：负责进行投票的发起和决议，更新系统状态；
2. 学习者(Learner)：包括跟随者（Follower）和观察者（Observer）；
3. Follower：用于接受客户端请求并向客户端返回结果，在选主过程中参与投票；
4. Observer：可接受客户端请求，将写请求转发给Leader，但Observer不参加投票过程，只同步Leader的状态，Observer的目的是为了扩展系统，提高读取速度；
5. 客户端(Client)：是指请求的发起方。
3）分析ZooKeeper的目录结构并对比节点类型？
1. 在机器的zookeeper/bin目录下输入./ zkCli.sh start后，就可以启动zookeeper集群（可以只启动一部分Server节点）
2. 输入./zkCli.sh -server 127.0.0.1:2181 ，即可进入查看zookeeper的目录
3. 数据模型
- ZooKeeper拥有一个层次的命名空间，图中每个方块是一个Znode
- Znode既可以像文件一样维护着数据、元信息、ACL、时间戳等数据结构
- Znode又可以像目录一样可以作为路径标识（必须为绝对路径）的一部分
- 用户对Znode具有增、删、改、查等操作（权限允许的情况下）
4. Znode类型
ZooKeeper中的节点有两类四种，节点的类型在创建时即被确定，并且不能改变：
PERSISTENT：永久节点
EPHEMERAL：临时节点
PERSISTENT_SEQUENTIAL：永久节点、序列化
EPHEMERAL_SEQUENTIAL：临时节点、序列化
临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，也可以手动删除。注：ZooKeeper的临时节点不允许拥有子节点。
永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。
序列化：当创建Znode的时候，用户可以请求在ZooKeeper的路径结尾添加一个递增的计数。
4）为什么hbase，kafka要基于zookeeper，zookeeper有哪些特征？
在设计之初就是为了依托于zookeeper的5大特征：
1. Watches机制
- 客户端可以在Znode上设置watch（监控器）
- 当节点状态发生改变时(数据的增、删、改)将会触发watch，向客户端发送且仅发送一条通知
- 存在有可能看不到所有数据变化的风险，因为多个事件的监控只会触发一次
2. 一致性保证
- 序列一致性：客户端发送的更新将按序在Zookeeper进行更新
- 原子一致性：更新只能成功或者失败，没有中间状态
- 单系统镜像：无论连接哪台Zookeeper服务器，客户端看到的服务器数据一致
3. 数据访问
- 每个节点上的“访问控制链”(ACL, Access Control List)保存了各客户端的访问权限。
- 表示为scheme:id:permissions（验证模式，用户，权限）
4. 容错性
- ZooKeeper集群中只要半数以上的机器处于可用状态，它就能够提供服务。
- 若少于半数的机器出现故障，则最少有一台机器会保存最新的状态，那么这台机器就是新的Leader，其余的副本最终也会更新到这个状态
- 若Leader挂了，由于其他机器保存了Leader的副本，可以从中选出一台机器作为Leader继续提供服务
5. 实时性
在任何客户端的系统视图上的的时间间隔是有限的，因此他在超过几十秒的时间内部会过期。这就意味着，服务器不会让客户端看一些过时的数据，而是关闭，强制客户端转到一个更新的服务器上。
5）zookeeper有哪些应用场景？
1. 配置管理（Configuration Management）
– 基于watch机制的全局系统配置
– 容错并且统一
2. 集群管理（Group Membership）
①集群状态
– 采用EPHEMERAL临时节点
– 所有的server getChildren(String path, boolean watch) 方法
– 某台服务器下线，对应的节点自动删除
②选主节点
– 采用EPHEMERAL_SEQUENTIAL临时序列节点
– 选择当前是最小编号的 Server 为 Master
– 最小编号的 Server 死去，由于是 EPHEMERAL节点，死去的Server 对应的节点也被删除，所以当前的节点列表中又出现一个最小编号的节点
3. 共享锁（Locks）
– 采用EPHEMERAL_SEQUENTIAL临时序列节点
4. 队列管理
①同步队列
– 采用EPHEMERAL_SEQUENTIAL临时序列节点
②FIFO队列
– 采用EPHEMERAL临时节点
– 保证所有成员加入队列时都有编号
– 出队列时通过getChildren( ) 方法返回所有元素，然后消费其中最小的一个
6）怎么解决zookeeper的Split-Brain（俗称脑裂）问题？是什么原因造成的？
首先什么是Split-Brain呢？
假死：由于心跳超时（网络原因导致的）认为master死了，但其实master还存活着。
脑裂：由于假死会发起新的master选举，选举出一个新的master，但旧的master网络又通了，导致出现了两个master ，有的客户端连接到老的master 有的客户端链接到新的master。
总结：出现这个问题的主要原因是Zookeeper集群和Zookeeper client判断超时并不能做到完全同步，也就是说可能一前一后，如果是集群先于client发现，那就会出现上面的情况。同时，在发现并切换后通知各个客户端也有先后快慢。一般出现这种情况的几率很小，需要master与Zookeeper集群网络断开但是与其他集群角色之间的网络没有问题，还要满足上面那些情况，但是一旦出现就会引起很严重的后果，造成数据不一致。
要解决Split-Brain的问题，一般有3种方式:
1、Quorums（法定人数），比如3个节点的集群，Quorums = 2, 也就是说集群可以容忍1个节点失效，这时候还能选举出1个lead，集群还可用。比如4个节点的集群，它的Quorums = 3，Quorums要超过3，相当于集群的容忍度还是1，如果2个节点失效，那么整个集群还是无效的
2、采用Redundant communications，冗余通信的方式，集群中采用多种通信方式，防止一种通信方式失效导致集群中的节点无法通信。
3、 Fencing, 共享资源的方式，比如能看到共享资源就表示在集群中，能够获得共享资源的锁的就是Leader，看不到共享资源的，就不在集群中。