下面谈一下Zookeeper的内部原理及应用场景，面试只要问到Zookeeper，下面就是重点。
一、内部原理
1.谈一谈Zookeeper集群的选举机制
1）半数机制：集群中半数以上机器存活，集群可用。所以zookeeper适合装在奇数台机器上。
2）Zookeeper虽然在配置文件中并没有指定master和slave。但是，zookeeper工作时，是有一个节点为leader，其他则为follower，Leader是通过内部的选举机制临时产生的。
3）以一个简单的例子来说明整个选举的过程。
假设有五台服务器组成的zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么。
（1）服务器1启动，此时只有它一台服务器启动了，它发出去的信息没有任何响应，所以它的选举状态一直是LOOKING状态。
（2）服务器2启动，它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3)，所以服务器1、2还是继续保持LOOKING状态。
（3）服务器3启动，根据前面的理论分析，服务器3成为服务器1、2、3中的老大，而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的leader。
（4）服务器4启动，根据前面的分析，理论上服务器4应该是服务器1、2、3、4中最大的，但是由于前面已经有半数以上的服务器选举了服务器3，所以它只能接收当小弟的命了。
（5）服务器5启动，同4一样当小弟。
2.节点类型
1）Znode有两种类型：
短暂（ephemeral）：客户端和服务器端断开连接后，创建的节点自动删除
持久（persistent）：客户端和服务器端断开连接后，创建的节点不删除
2）Znode有四种形式的目录节点（默认是persistent ）
（1）持久化目录节点（PERSISTENT）
客户端与zookeeper断开连接后，该节点依旧存在
（2）持久化顺序编号目录节点（PERSISTENT_SEQUENTIAL）
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
（3）临时目录节点（EPHEMERAL）
客户端与zookeeper断开连接后，该节点被删除
（4）临时顺序编号目录节点（EPHEMERAL_SEQUENTIAL）
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号
3.谈一谈Zookeeper的监听器原理
常见的监听有对节点数据变化的监听和对节点路径变化的监听
1）首先要有一个main()线程
2）在main线程中创建Zookeeper客户端，这时就会创建两个线程，一个负责网络连接通信（connet），一个负责监听（listener）。
3）通过connect线程将注册的监听事件发送给Zookeeper。
4）在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中。
5）Zookeeper监听到有数据或路径变化，就会将这个消息发送给listener线程。
6）listener线程内部调用了process（）方法。
4.Zookeeper将数据写入的流程是什么？谈一谈
5.stat结构体
二、应用场景
1.分布式锁
分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
（1）所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看作是一把锁，通过create znode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁，需要创建一个临时节点
假设现在有两个客户端要操作对应的两台做好主从数据同步的数据库A和数据库B，都需要对其中的某个数据的num属性进行++操作，如果同时去操作就有可能会出现数据安全问题，这时可以使用Zookeeper临时节点的不可重复创建特性以及下线即删除特性来做一个分布式锁。
可以在Zookeeper中创建一个节点，/users，每当客户端要操作数据库中对应的user时都将其uuid当作这个节点下子节点的K，即/users/00001，当客户端操作服务器时，先去判断要操作的用户在对应的节点上是否存在，如果不存在则创建一个临时节点，去操作数据库，做数据库同步之后断开连接释放节点，如存在则证明有其他客户端正在对此用户的数据进行操作，就不允许同时进行操作了，这个节点就相当于一把锁。
伪代码：if 当前用户对应的节点不存在
创建一个临时节点
操作数据库
做数据库的主从同步
断开连接释放节点
else
拿不到锁之后的具体业务逻辑
（2）控制时序，就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这里/distribute_lock 已 预先存在 ， 客 户 端 在 它 下 面 创 建 临 时 有 序 节 点 （ 这 个 可 以 通 过 节 点 的 属 性 控 制 ：
CreateMode.EPHEMERAL_SEQUENTIAL来挃定）。Zk的父节点（/distribute_lock）维持一份sequence,保证子节点创建的时序性，从而也
形成了每个客户端的全局时序。
2.统一命名服务
3.统一配置管理
4.统一集群管理
5.服务器动态上下线监听
6.软负载均衡
