不久，Apache的卡夫卡®将不再需要的ZooKeeper！借助KIP-500，Kafka将包括其自己的内置共识层，从而完全消除ZooKeeper依赖性。这项工作的下一个重要里程碑是Apache Kafka 2.8.0，您可以在此早期访问新代码，可以在不使用ZooKeeper的情况下启动Kafka的开发版本，并有机会使用Raft实现分布式共识算法。
博客文章Apache Kafka拿走zookeeper：删除Apache ZooKeeper依赖关系讨论了外部元数据管理，主要体系结构更改以及ZooKeeper删除如何改善Kafka的问题。最终，删除ZooKeeper可以简化Kafka部署的总体基础架构设计和操作流程。我们汇总了简化后产生的具体好处，并特别关注您将能够停止做的事情。事实证明，您可以停止很多事情，而我们认为您不会错过它们。
一旦ZooKeeper从Kafka中删除为依赖项，您的生活就会在几个不同的地方变得更加轻松：
运维
容量规划和磁盘
性能
监控方式
故障排除
运维
ZooKeeper是与Kafka完全独立的系统，具有自己的部署模式，配置文件语法和管理工具。如果从Kafka中删除ZooKeeper，则不再需要管理单独的服务。更重要的是，使用KIP-500，您可以选择将controller和broker部署在同一JVM中，从而进一步简化了管理。您现在可以停止：
＃1： 了解并操作另一个分布式系统(zookeeper)
＃2： 为ZooKeeper服务器管理其他服务器，VM或容器
＃3： 为ZooKeeper设置单独的安全配置，该配置与Kafka集群的其余部分不同
＃4： 想知道它是拼写的ZooKeeper还是Zookeeper
＃5： 每当您看到它拼写为Zookeeper时就叹气
＃6：使用
systemctl
另一种Linux服务（相比之下，使用KIP-500，控制器和代理可以选择在同一JVM中运行）＃7：维护另一个属性文件的版本控制（与上述条件相同）
＃8：在Kafka和非Kafka服务之间共享ZooKeeper合奏
＃9：由于Kafka群集分区限制，重新设计主题和键模式（相比之下，对于KIP-500，Kafka群集支持数百万个分区）
＃10：将代理超时调整为ZooKeeper，您现在可以忘记
zookeeper.connection.timeout.ms
和zookeeper.session.timeout.ms＃11：质疑为什么你不能只经营kafka
＃12：阅读ZooKeeper发行说明，以了解升级时新功能的可用性
＃13：功能行为发生变化（例如需要明确允许四个字母词）时更新ZooKeeper配置
＃14：作为补丁管理最佳实践的一部分，对ZooKeeper集成执行季度滚动重启
＃15：谈论您迫不及待要等待KIP-500的时间
容量规划和磁盘
存储是ZooKeeper部署的主要考虑因素，没有ZooKeeper，您就不必处理ZooKeeper的容量规划，磁盘问题和快照。您现在可以停止：
＃16：完成每个ZooKeeper服务器的大小调整练习
＃17：在运行Kafka代理的同一台服务器上并排放置ZooKeeper服务。除非负载真的很低，否则通常不建议这样做，但是我们知道有些人仍然会尝试！
＃18：计算出ZooKeeper集合中应该包含的服务器数量，以平衡读取容量和写入容量（某些Kafka群集的ZooKeeper节点与Kafka节点一样多）
＃19：购买固态驱动器（SSD），由于延迟敏感度，建议将其用于ZooKeeper服务器
＃20：在初始安装过程中发现ZooKeeper服务器没有必要的卷挂载
＃21：共享ZooKeeper事务日志和快照目录的目录路径
＃22：设置清除旧ZooKeeper数据的策略-您现在可以忘记
autopurge.purgeInterval
和autopurge.snapRetainCount＃23：将ZooKeeper快照迁移到容量更大的新驱动器
性能
KIP-500的主要变化之一是改善了控制平面的流量。如果没有KIP-500，代理操作需要从ZooKeeper中读取所有主题和分区的元数据，这在大型集群中可能需要很长时间。使用KIP-500时，代理将元数据本地存储在日志中，并且仅从控制器读取最新的一组更改（类似于Kafka使用者如何读取日志的最后而不是整个日志），从而改善了O（ N）至O（1）。因此，这些控制平面操作具有明显更好的性能，因此您现在可以停止：
＃24：在控制器代理失败后转动手指，等待选举新的控制器并从ZooKeeper重建状态（相比之下，对于KIP-500，可以选择备用控制器，并且它已经具有状态）
＃25：等待代理是否需要重新启动然后读取完整状态（相比之下，对于KIP-500，代理在整个过程重新启动时都保留其元数据缓存）
＃26：主题创建会产生O（N）费用（相比之下，使用KIP-500，主题创建不再需要从Zookeeper元数据中获取主题的完整列表，时间仅为O（1），向主题添加元数据事件日志）
＃27：删除主题所需的O（N）费用
监控方式
必须监视您的关键任务部署中的任何服务，并且如果您使用的是ZooKeeper，则必须像对Kafka部署中的所有其他服务一样对其进行监视。因此，如果您删除ZooKeeper，则可以停止：
＃28：在繁忙的Grafana Kibana / Datadog监控仪表板中迷路，这些仪表板显示了许多ZooKeeper指标
＃29：搞清楚什么警戒级别，ZooKeeper JMX的指标，你现在可以忘掉
NumAliveConnections
，OutstandingRequests
，AvgRequestLatency
，MaxRequestLatency
，HeapMemoryUsage
，等。＃30：搞清楚什么警报级别上设置这关系到动物园管理员，你现在可以忘记卡夫卡JMX指标
ZooKeeperDisconnectsPerSec
，ZooKeeperExpiresPerSec
，ZooKeeperReadOnlyConnectsPerSec
，ZooKeeperSyncConnectsPerSec
，ZooKeeperAuthFailuresPerSec
，ZooKeeperSaslAuthenticationsPerSec
，等。＃31：当ZooKeeper服务器出现故障时回答深夜页面
＃32：当ZooKeeper服务器上的磁盘利用率超过配置的阈值时收到警报
＃33：为额外的日志文件设置日志管理
＃34：使用独特的格式化程序读取ZooKeeper事务日志和快照以调查问题-您现在可以忘记
org.apache.zookeeper.server.LogFormatter
和org.apache.zookeeper.server.SnapshotFormatter
故障排除
如果您的Kafka部署中出现问题，ZooKeeper会创建一个需要调查的附加元素。如果没有ZooKeeper，则故障排除可以集中在核心组件上，因此您现在可以停止：
＃35：具有
/var/log/messages
文件从详细的在网络中断期间日志填满＃36：如果尚未从ZooKeeper迁移客户端和工具，则对ZooKeeper集成和Kafka客户端之间的IP连接问题进行故障排除
＃37：处理与控制器和ZooKeeper之间的状态分歧有关的问题（相比之下，对于KIP-500，代理程序不按顺序向代理发送通知，而是按顺序使用元数据事件日志中的所有事件）
＃38：发现Kafka群集配置为连接到错误的ZooKeeper集成时进行故障排除问题（相比之下，对于KIP-500，当代理和控制器位于同一位置时，这种情况不太可能出现）
＃39：在升级ZooKeeper时遇到并解决影响生产的意外问题
＃40：升级后ZooKeeper无法启动时出汗，例如缺少快照文件时
＃41：尝试记住某个分层结构中某个znode的位置
＃42：通过运行手册挖的命令找出哪个ZooKeeper的服务器是当你的主机没有领导者
nc
安装，可能是由于企业策略（提示：echo srvr | (exec 3<>/dev/tcp/zk-host/2181; cat >&3; cat <&3; exec 3<&-) | grep -i mode
）
