科技之感|为什么Kafka依赖ZooKeeper？( 二 ) 一、ZooKeeper简介1.基本介绍ZooKeeper

顾名思义，该类节点结合了临时节点和顺序节点的特征，在创建节点时， ZooKeeper根据创建的时间顺序给该节点名称进行编号，当创建节点的客户端和ZooKeeper断开连接后，节点自动删除。创建时添加-e-s参数即可。
ZooKeeper实现分布式锁就是利用了临时顺序节点。
首先在ZooKeeper中创建一个持久节点ParentLock ，每当有客户端想要获得锁时，就在ParentLock下创建一个临时顺序节点，如果该节点是第一个，则获得锁，如果不是，则找到排序比它靠前的一个节点并注册Watcher ，用于监听节点是否存在。若第一个节点运行完毕，其客户端会调用指令删除该节点，或者其客户端崩溃，第一个节点也会自动删除，而第二个节点监听到该节点被删除，再经过查询确认就能获得锁了。不难发现ZooKeeper实现的分布式锁相当于是一个等待锁的队列，能够提升抢锁的效率，但是因为需要创建和删除节点，导致性能较低。
二、Kafka+ZooKeeper
ZooKeeper作为给分布式系统提供协调服务的工具被kafka所依赖。在分布式系统中，消费者需要知道有哪些生产者是可用的，而如果每次消费者都需要和生产者建立连接并测试是否成功连接，那效率也太低了，显然是不可取的。而通过使用ZooKeeper协调服务， Kafka就能将Producer ， Consumer ， Broker等结合在一起，同时借助ZooKeeper ， Kafka就能够将所有组件在无状态的条件下建立起生产者和消费者的订阅关系，实现负载均衡。

文章图片
1）Broker信息
在ZooKeeper上会有一个专门用来进行Broker服务器列表记录的节点，节点路径为/brokers/ids 。 Kafka的每个Broker启动时，都会在ZooKeeper中注册，创建/brokers/ids/[0-N]节点，写入IP ，端口等信息，每个Broker都有一个BrokerId 。 Broker创建的是临时节点，在连接断开时节点就会自动删除，所以在ZooKeeper上就可以通过Broker中节点的变化来得到Broker的可用性。
2）Topic信息
在Kafka中可以定义很多个Topic ，每个Topic又被分为很多个Partition 。一般情况下，每个Partition独立在存在一个Broker上，所有的这些Topic和Broker的对应关系都由ZooKeeper进行维护。
3）负载均衡
生产者需要将消息发送给Broker ，消费者需要从Broker上获取消息，通过使用ZooKeeper ，就都能监听Broker上节点的状态信息，从而实现动态负载均衡。
4）offset信息
在上一篇博客中提到过， offset用于记录消费者消费到的位置，在老版本（0.9以前）里offset是保存在ZooKeeper中的。
5）Controller选举
在Kafka中会有多个Broker ，其中一个Broker会被选举成为Controller（控制器），在任意时刻， Kafka集群中有且仅有一个控制器。 Controller负责管理集群中所有分区和副本的状态，当某个分区的leader副本出现故障时，由Controller为该分区选举出一个新的leader 。 Kafka的Controller选举就依靠ZooKeeper来完成，成功竞选为Controller的Broker会在ZooKeeper中创建/controller这个临时节点，在ZooKeeper中使用get命令查看节点内容：

文章图片
其中“version”在目前版本中固定为1 ， “brokerid”表示Broker的编号， “timestamp”表示竞选称为Controller时的时间戳。
当Broker启动时，会尝试读取/controller中的“brokerid” ，如果读取到的值不是-1 ，则表示已经有节点竞选成为Controller了，当前节点就会放弃竞选；而如果读取到的值为-1 ， ZooKeeper就会尝试创建/controller节点，当该Broker去创建的时候，可能还有其他Broker一起同时创建节点，但只有一个Broker能够创建成功，即成为唯一的Controller 。