分布式应用，ZooKeeper做了什么？
一个分布式应用，发生局部故障是非常麻烦的事。一个数据包在节点之间传递，网络故障，发送方不知道接收方是否接收到了数据。针对分布式应用，我们新增加一层协调者，来管理子进程是一种常见的解决方案。ZooKeeper就是用来做协调任务的。
ZK核心功能是什么？
答：简单来说，客户端连接ZK，监听ZK上的数据。如果有人修改了ZK中被监听的数据，ZK反过来会告诉客户端数据的变更。
举个栗子:
在Kafka的设计中，Kafka的一个节点在ZK中创建了一个数据，谁先创建成功谁就是集群的主节点，其余的节点都会去监听这个数据。
如果主节点宕机了，ZK对应的数据就会发生变更，既而监听这个数据的其余节点就会感知到主节点宕机了，然后Kafka就需要进行选举。
ZK的的架构师怎么设计的？
答：在 zookeeper 集群中， 集群的角色有可以有三种：leader, follower, observer
- leader，为客户端提供读写功能。在选举中负责投票的发起和决议。
- follower，为客户单提供读服务，写请求转发给leader。在选举中进行投票。
- observer，为客户端提供读服务，写请求转发leader。不参与一致性协议过半写入和选举机制，只为提高读性能。
三者关系如下：
作为分布式应用，数据一致性很关键，ZK怎么做?
答：说到数据一致性，就离不开一致性算法。ZK采用的ZAB（Zookeeper Atomic BroadCast）协议实现数据一致性。主要有数据写入和故障恢复（选举）模式。
数据写入--过半写机制流程
（1）ZooKeeper写数据都是leader节点，leader节点会把数据通过proposal请求发送到所有节点
（2）所有节点收到数据以后都会写到自己到本地磁盘上面，成功后发送一个ack请求给leader
（3）leader只要接受到过半的节点ack响应，就会发送commit消息给各个节点，各个节点就会把消息放入到内存中
（4）返回客户端写入成功
故障恢复--选主模式流程
ZAB的选举发生在服务启动和leader节点异常时。用服务启动举个例子。假设有三台服务器组成的ZK集群，它们的serverid从1-3，假设这些服务器依序启动，来看看会发生什么：
（1）1启动，此时只有它一台服务器启动了，它发出去的报没有任何响应，所以它的选举状态一直是LOOKING状态
（2）2启动，它与服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以ID值较大的服务器2胜出
（3）此时二台服务器（超过半数）选举了服务器2，所以它成为了这次选举的leader
（4）3启动，根据前面的分析，理论上服务器3应该是服务器1,2,3中最大的，但是由于前面已经有半数以上的服务器选举了服务器2，所以它只能接收当小弟的命了
总结：
- ZooKeeper是应用很广的协调服务
- Zookeeper主动通知客户端数据的变更
- 数据一致性是协调者很重要的特点