最近刚好在啃Kafka，看到Kafka可能在移除zookeeper依赖的消息。本文共1486字，读完预计需要4分钟。
提到消息队列，很多人应该第一时间想到的就是Kafka吧。简单的来说，生产者生产数据，存储在Kafka Broker当中，然后可以被消费者消费。
至于ZooKeeper，从字面上来看就是动物园管理员的意思，其实是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
Kafka严重依赖于ZooKeeper集群。所有的broker在启动的时候都会往zookeeper进行注册，目的就是选举出一个controller，controller会读取注册上来的从节点的数据（通过监听机制），生成集群的元数据信息，之后把这些信息都分发给其他的服务器，让其他服务器能感知到集群中其它成员的存在 。通过这个方法让整个集群都得知这个分区方案，此时从节点就各自创建好目录等待创建分区副本即可。这也是整个集群的管理机制。
1 问题
实际上，问题不在于ZooKeeper本身，而在于外部元数据管理的概念上。
Kafka和ZooKeeper其实是两个系统，我们常用的Kafka其实整合了ZooKeeper的，然而每个都有其自己的网络通信，安全性，监视和配置方式。使用两个系统会使程序员的工作量翻倍。这导致学习成本过高，并增加了某些配置错误而导致安全漏洞的风险。
其次，因为ZooKeeper中的数据也需要反映在Kafka控制器上，这会导致双重缓存。
另外，正如前面提到的，当Kafka集群启动的controller时，controller必须从ZooKeeper加载集群的完整状态。随着数据量的增加，此加载过程的时间也随之增加。
最后，将数据存储在外部会增加controller的内存与外部状态不同步的可能性。
2 KIP-500
为此Apache启动了一个KIP-500的项目，将Kafka的元数据存储在Kafka本身中，而不是存储在ZooKeeper之类的外部系统中。将controller作为分区的负责人。
拥有的分区和元数据越多，controller的可伸缩性就越重要。当前，当Kafka选择新controller时，它需要在继续之前加载整个集群状态。随着群集元数据数量的增加，此过程将花费越来越长的时间。相比之下，KIP-500架构下，只要active controller消失，就会有几个备用controller准备接管。这种设计确保了当选择一个新的controller时，不需要经过漫长的加载过程。
左图表示当前Kafka架构，右图表示KIP-500架构，其中「铲屎官」代表ZooKeeper，圈圈表示控制器。
KIP-500将加快topic的创建和删除。当前，创建或删除topic时，controller必须从ZooKeeper重新加载集群中所有topic名称的完整列表，因为当集群中的主题集发生更改时，当ZooKeeper通知我们时，它并不能准确告诉我们添加或删除了哪些主题。在KIP-500的设计中，创建或删除topic将仅涉及在元数据分区中创建新条目，复杂度仅为O(1)。元数据可伸缩性是将来扩展Kafka的关键部分。Apache期望单个Kafka集群最终将能够支持一百万个分区或更多。
3 最后
Kafka还是有必要学一学的，无论是用来做消息订阅、还是大数据存储或者流数据处理很重要的。KIP-500已经发行了bridge版本，有机会尝尝鲜。
