Kafka中ZooKeeper与Controller Broker的职责差异相关问题咨询

问题1：ZooKeeper在Kafka集群管理中的职责是否仅为选举Controller？ #

ZooKeeper的作用远不止Controller选举，还承担了大量核心集群管理工作，具体包括：

• 集群元数据持久化存储：所有topic的分区配置、副本分布、ISR列表、集群全量broker节点信息等核心元数据，都会持久化存储在ZK的节点中，Controller更新元数据后会同步到所有broker节点
• 集群配置管理：全局topic默认配置、用户权限规则、流量配额配置等集群级别的配置项，默认都存储在ZK中，保证配置在集群内全局一致
• 节点存活状态感知：依赖ZK的临时节点机制，broker启动时会在ZK上注册临时节点，一旦broker宕机断开连接，对应临时节点会自动删除，Controller会第一时间感知到节点下线，触发副本故障转移流程
• 旧版本消费者位移存储：Kafka 0.9版本之前还没有内置位移主题，消费者的消费进度全部存储在ZK节点中。

问题2：Producer、Consumer无需和ZooKeeper交互的原因是什么？ #

这个设计是Kafka 0.9版本架构优化的结果，核心原因如下：

• 所有集群元数据已经由Controller同步到集群内的每一个broker节点，broker本身就可以响应客户端的元数据查询请求
• 客户端只要配置了任意可用的broker地址，就可以向该broker发送MetadataRequest请求，获取到全量集群元数据，包括topic分区分布、分区leader节点地址、全量broker列表等所有客户端运行需要的信息
• 消费者的位移存储从ZK迁移到了Kafka内置的专属主题__consumer_offsets，位移的提交、查询操作都直接和该主题分区对应的leader broker交互即可，完全不需要访问ZK
• 该设计既降低了ZK的访问压力，避免ZK成为集群访问的单点瓶颈，也简化了客户端的配置逻辑，用户不需要再为客户端维护ZK地址列表，仅配置broker列表即可。

内容的提问来源于stack exchange，提问作者Kumar