前言：在我们了解kafka为什么依赖zookeeper之前，首先要先知道zookeeper自身的一个基础架构和作用
“所有一切的努力都是为了自己的名字”
Zookeeper概念扫盲
基本概述
ZooKeeper是一个分布式协调服务，它的主要作用是为分布式系统提供一致性服务
数据结构
?ZooKeeper的数据存储也同样是基于节点，这种节点叫做Znode。每一个Znode里包含了数据、子节点引用、访问权限等.
- data即Znode里面的数据
- ACL为权限规则，它规定了哪些用户或哪些IP才有权限访问此Znode
- stat记录了Znode相关的元数据，比如事务ID、版本号、时间戳、大小
- child为当前节点的子节点引用，类似于二叉树的左孩子右孩子
ZooKeeper有个限制，就是每个Znode的数据大小不会超过1M。
节点类型
持久节点:在节点创建后，就一直存在，直到有删除操作来主动清除这个节点——不会因为创建该节点的客户端会话失效而消失。
持久顺序节点:(节点会自动加上编号)：额外的特性是，在ZK中，每个父节点会为他的第一级子节点维护一份时序，会记录每个子节点创建的先后顺序.
临时节点：临时节点的生命周期会和客户端会话绑定，即如果客户端会话失效（不是连接端口），那么这个节点就会自动被清除掉。另外，在临时节点下面无法创建子节点。
临时顺序节点：此节点是属于临时节点，不过带有顺序，客户端会话结束节点就消失。
集群角色
ZooKeeper集群中有一个leader，多个follower角色，其中leader提供写服务，follower提供读服务。
Leader的选举机制
Leader作为整个ZooKeeper集群的主节点，负责响应所有对ZooKeeper状态变更的请求。
Leader选举：集群初始化阶段，一台服务器server是完成选举的，两台之间能够互相通信，每台机器试图找到一个Leader。由此进入选举机制。
投票基于Sid(服务器id)和ZXid(事务id)，优先查找ZXid，以数据最新的作为Leader。如果ZXid一样大，就比较Sid,这里有个过半的概念，大于集群机器数量的一半，即大于或等于（n/2+1）
zookeeper监听机制
- 当客户端关注的节点发生变化（数据改变、节点删除、子目录节点增加删除），zk会通知客户端，监听机制保证zk保存的任何的数据的任何改变都能快速的响应到监听了该节点的应用程序
总结
- Znode系统，存储一些关键数据，类似于unix文件系统
- watch监听机制，可以让客户端有能力实时感知zookeeper代为保管的数据的变化，从而进行相应处理。
那么kafka为什么依赖zookeeper呢？
ZooKeeper 作为给分布式系统提供协调服务的工具被 kafka 所依赖。在分布式系统中，消费者需要知道有哪些生产者是可用的，而如果每次消费者都需要和生产者建立连接并测试是否成功连接，那效率也太低了，显然是不可取的。而通过使用 ZooKeeper 协调服务，Kafka 就能将 Producer，Consumer，Broker 等结合在一起，同时借助 ZooKeeper，Kafka 就能够将所有组件在无状态的条件下建立起生产者和消费者的订阅关系，实现负载均衡?
1.Brork管理
在Kafka的设计中，选择了使用Zookeeper来进行所有Broker的管理，体现在zookeeper上会有一个专门用来进行Broker服务器列表记录的点，节点路径为/brokers/ids
Zookeeper用一个专门节点保存Broker服务列表，也就是?/brokers/ids。
broker启动时，向Zookeeper发送注册请求，Zookeeper会在/brokers/ids下创建这个broker节点，如/brokers/ids/[0...N]，并保存broker的IP地址和端口，Broker 创建的是临时节点，在连接断开时节点就会自动删除，所以在 ZooKeeper 上就可以通过 Broker 中节点的变化来得到 Broker 的可用性。
?2、负载均衡
broker向Zookeeper进行注册后，生产者根据broker节点来感知broker服务列表变化，这样可以实现动态负载均衡。
3、Topic 信息
在 Kafka 中可以定义很多个 Topic，每个 Topic 又被分为很多个 Partition。一般情况下，每个 Partition 独立在存在一个 Broker 上，所有的这些 Topic 和 Broker 的对应关系都由 ZooKeeper 进行维护。
4、Controller 选举