1. 首先zookeeper是什么
zookeeper是一个开放源代码的分布式应用程序协调服务，可以把它看成是整个集群的管理者，监视者。
2. zookeeper能做什么
它可以实现诸如分布式应用配置管理、统一命名服务、状态同步服务、集群管理等功能。
3. zookeeper服务与kafka集群的联系
这里首先说一下broker的概念：Kafka 集群包含一个或多个服务器，这种服务器被称为 broker，每个broker服务器都要连接到zk服务。
- 一个典型的kafka集群中包含若干个producer（生产者），若干broker（一般broker越多，集群吞吐率越高），若干consumer group（消费组），以及一个zookeeper服务。
- kafka通过zookeeper管理集群配置，选举leader，以及在消费组发生变化时进行rebalance。
- producer使用push模式将消息发布到broker，consumer使用pull模式从broker订阅并消费消息。
4. Leader选举流程。
选举流程主要出现在以下两种情况发生时：
（1）服务器初始化启动时；
（2）服务器在运行期间leader出现故障。
由于涉及到算法和流程较复杂，这里就以个人理解浅显的描述以下选举过程，如有不当的地方欢迎指正。
当服务器在初始化时启动：
假设集群中共有3台机器，分别使用server1、server2、server3等来表示，按编号以此启动起来。
第一步：每个server发起一个投票，推荐自己作为leader服务器，投票内容为（Serverid，Zxid），分别表示服务器ID、数据ID（服务器中存放定的最大数据ID）。由于server1先启动，它的投票为（1，0），然后进入Looking状态；
第二步：server2启动，发起投票为（2,0），并与已启动的server1交换结果，由于server2的编号2大于1，因此胜出，并告知server1。
第三步：server1将自己的投票改为（2,0），并重新投票。而server继续维持之前投票（2,0）。这个时候统计第二轮投票，server2以两票胜出，同时判断当前投票人数为2，已经超过3台服务器的50%，因此结果生效，server2当选为Leader，状态变为LEADING；server1状态变为FOLLOWING。
第四部：此时server3启动，发现Leader已经存在，则直接将自己的状态调整为FOLLOWING。
注意：如果集群中有5台机器，那么由于投票人数不足50%，则需要保持Looking状态，继续等待新的投票者加入，直到超过50%为止。
当服务器在运行期间leader出现故障：
第一步：假设server2作为leader挂了之后，剩下所有机器都会将自己的状态改为LOOKING，然后开始Leader选举过程。
第二步：server1发出投票为（1，233），server3发出投票为（3,222）。
第三步：两台机器互相接收来自别的服务器的投票，判断投票的有效性（是否来自LOOKING状态的服务器），然后进行将别人的投票与自己的投票进行PK，PK规则如下：1.优先检查Zxid，Zxid较大的优先作为leader；2.如果Zxid相同，那么Serverid较大的胜出。对于当前情况来看，server1胜出。
第四步：发起第二轮投票，server3将自己投票改为（1,233），server1保持不变（1,233），此时判断投票人数超过半数，server1胜出，当选为新leader。server1状态改为LEADING，server3状态改为FOLLOWING。
参考文章：《zookeeper的leader选举过程》
https://blog.csdn.net/virtil33/article/details/94343215