Zookeeper是什么
Zookeeper是一个分布式的，开源的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和HBase导致重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步，组服务等。
为什么使用Zookeeper
- 大部分的分布式应用程序都需要一个主控、协调器或者控制器来物理分布的子进程（如资源，内存分配等）
- 目前大部分应用开发私有的协调程序，缺乏一个通用性
- 协调程序的反复编写浪费，难以形成通用、伸缩性好的协调器
- ZooKeeper：提供通用的分布式锁服务，用以协调分布式应用
Zookeeper三种角色
Leader
整个Zookeeper集群工作机制中的核心。Leader作为整个Zookeeper集群的主节点，负责响应所有对Zookeeper状态变更的请求。
主要工作：
- 事务请求的唯一调度和处理，保证集群处理事务的顺序性
- 集群内各服务的调度者。
Follower
是Zookeeper集群状态的跟随者。它的逻辑相对简单。除了响应本服务器上的读请求外，follower还要处理leader的提议，并在leader提交该提议时在本地也进行提交。另外需要注意的是，leader和follower构成Zookeeper集群的法定人数，也就是说，只有它们才参与新leader的选举，响应leader的提议。
Observer
观察者。如果Zookeeper集群的读取负载很高，或者客户端多到跨机房，可以设置一些observer服务器，以提高读取的吞吐量。Observer和Follower比较相似，只有一些小区别：
- 首先Observer不属于法定人数，即不参加选举也不响应提议，也不参与写操作的过半写成功策略
- observer不需要将食物持久化到磁盘，一旦observer被重启，需要从leader重新同步整个名字空间
Zookeeper Leader选举过程
Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一是，需要进入Leader选举。
- 服务器初始化启动
- 服务器运行期间无法和Leader保持连接
服务器初始化时期Leader选举
- 每个Server发出一个投票。初始情况下，每个Server都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的myid和ZXID，使用（myid，ZXID）来表示，然后各自将这个投票发给集群中其他机器
- 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有小型，如检查是否是本轮投票、是否来自LOOKING状态的服务器。
- 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如果下：
- 优先检查ZXID。ZXID比较大的服务器优先作为Leader
- 如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。
- 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接收到相同的投票信息。
- 改变服务器状态。一旦确定了Leader。每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更状态为LEADING。
服务器运行期间Leader选举
- 变更状态。Leader挂后，余下的非Observer服务器都会讲自己的服务器状态变为LOKKING，然后开始进入Leader选举过程。
- 每个Server会发出一个投票。在运行期间，每个服务器上的ZXID可能不同，每个服务器向集群中多有机器发送投票信息（myid，ZXID）
- 接收来自各个服务器的投票。与启动时过程相同。
- 处理投票。与启动时过程相同。
- 统计投票。与启动时过程相同。
- 改变服务器的状态。与启动时过程相同。
