ZooKeeper（ZK）在Kafka集群中扮演元数据管理和协调的核心角色，其节点挂掉是否影响Kafka运行，需分情况讨论：
1.单节点挂掉（非Leader）
- 影响有限：ZK集群通常由奇数个节点组成（如3/5/7），采用多数投票机制（Quorum）。若挂掉的是Follower节点（非Leader），只要存活节点数仍满足 $\frac{N}{2}+1$（例如3节点集群需至少2个存活），集群仍能正常服务。
- Kafka表现：生产者（Producer）和消费者（Consumer）可继续收发消息，但以下操作可能受影响：
- Broker注册/注销；
- Topic分区扩容或Leader重选举（需ZK协调）；
- 消费者组（Consumer Group）的Rebalance。
2.Leader节点挂掉
- 短暂不可用：ZK需重新选举Leader（通常耗时 $\leq$ 200ms）。选举期间，ZK集群暂不可写，但读取操作仍可进行（因ZK状态最终一致）。
- Kafka表现：
- 若选举快速完成（秒级），Kafka可能无感知；
- 若选举延迟，Broker与ZK的心跳或元数据更新可能超时，触发Broker自保护（如关闭监听端口）。
3.多个节点挂掉（Quorum不满足）
- ZK集群瘫痪：当存活节点数 $\lt \frac{N}{2}+1$（如3节点挂2个），ZK丧失写入能力，无法更新状态。
- Kafka影响：
- 元数据冻结：新Broker无法注册，Topic无法扩容，分区Leader无法切换；
- 消费者异常：消费者组Rebalance失败，可能导致重复消费或消息堆积；
- 生产中断：若涉及分区Leader切换（如Broker宕机），生产者可能因元数据过期而发送失败。
4.持久性故障
若挂掉的ZK节点无法恢复：
- 需人工介入：替换节点并重启集群；
- 风险：若ZK数据未及时同步，可能丢失部分元数据（但ZK设计保证数据最终一致）。
总结建议
| 场景 | 影响程度 | 应对措施 |
|---|---|---|
| 单Follower节点挂掉 | 低 | 监控，等待自动恢复 |
| Leader节点挂掉 | 中 | 监控选举，必要时重启 |
| 多节点挂掉（Quorum丢失） | 高 | 立即修复ZK，优先恢复Quorum |
实际影响取决于ZK集群规模和Kafka配置（如zookeeper.session.timeout.ms）。建议至少部署3节点ZK集群，并配置监控告警。
