zk管理kafka有哪些不足

系列文章目录

---

一、不足

在一个健康的zk集群中，每时每刻只有一个健康的leader节点，zk必须保证半数以上的节点可用，才能保证zk集群可用。浪费资源。

zk和kafka是两个不同的系统，运维工作加倍。

controller节点存在单点故障。

controller宕机的话，新controller 需要从zk拉取所有分区的元数据信息，向每个broker节点发送leaderAndISR和updateMetaData请求，时间复杂度是O（num.partitions）。

broker宕机的话， 受控关机时间长，尤其是某个broker节点上分布的分区leader非常多时，需要重选leader，重新拉取元数据信息，分区越多重启时间越长，时间复杂度是O（partitions.leader）。

二、zk全部宕机后，kafka集群能正常收发消息吗？

能够正常收发消息。但是在kafka的server log里面，会报错：xxxx拒绝连接
原因是，kafka0.9以后，zk的功能被弱化，用来帮助kafka集群选举controller节点等基本操作，zk节点宕机后，kafka集群只是不能再发现新的broker节点加入了，但是不影响既有的节点收发日志。

三、controller功能和如何选举

1. 分区 Leader 选举
   当某个 Broker 宕机或重新加入时，Controller 负责重新选举该 Broker 上的分区 Leader。
   确保每个分区都有一个 Leader 和多个 Follower（副本）。
2. 分区分配与重平衡
   在集群扩容、Broker 故障恢复等情况下，Controller 会重新分配分区到不同的 Broker 上，以实现负载均衡。
   控制 Rebalance（再平衡）过程，确保所有副本同步。
3. 元数据管理
   维护并更新集群的元数据信息，如：
   Topic 的分区数量
   分区的 Leader 和副本信息
   Broker 的状态（在线/离线）
   Controller 自己的状态（主/备）
4. 监控 Broker 状态
   检测 Broker 是否正常运行。
   如果某个 Broker 失联，Controller 会触发相应的处理逻辑（如重新分配分区）。
5. 控制副本同步
   确保副本之间的数据同步，防止数据丢失

集群的启动中，如何选出controller: 抢占机制