常见故障排查

定义与作用

生产环境 Kafka 故障可归为三大类：不可用（连不上/读写失败）、性能差（Lag 飙升/延迟高）、数据异常（丢失/重复）。本节提供结构化的诊断流程，覆盖最常见的 6 个故障场景。

核心原理

故障诊断决策树

完整示例

故障 1：`NOT_ENOUGH_REPLICAS`

症状：Producer 报错 NOT_ENOUGH_REPLICAS，消息发送失败。

诊断：

# 1. 查看 ISR 状态
bin/kafka-topics.sh --describe --topic orders --bootstrap-server localhost:9092
# Partition: 0  Isr: 1   （只有 1 个副本在 ISR）
# Config: min.insync.replicas=2

# 2. 检查是否有 Broker 下线
bin/kafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe --status
# NodeId 2: Status FOLLOWER (not in ISR?) ← 确认

# 3. 恢复出问题的 Broker
# 或临时降低 min.insync.replicas
bin/kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics --entity-name orders \
  --alter --add-config min.insync.replicas=1

故障 2：Consumer Lag 持续增长

症状：kafka-consumer-groups.sh 显示 Lag 从 1000 增长到 100000。

诊断：

# 1. 确认 Lag 分布
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --group my-group --describe
# 看是否集中在某个分区

# 2. 检查 Consumer 是否频繁 Rebalance
grep "REBALANCE" /opt/kafka/logs/server.log
# Member xxx has left the group ← Consumer 可能处理太慢被踢

# 3. 检查 Consumer 端 max.poll.interval.ms
# 如果 Consumer 日志显示 poll 间隔 > 5min → 增加该参数或减少 max.poll.records

# 4. 检查 Consumer 实例数
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --group my-group --members --describe
# 确认 Consumer 数量是否不足

解决：

Lag 均匀分布 → 增加 Consumer 实例（不超过分区数）
Lag 集中在某几个分区 → 检查 Key 分布，考虑增加分区数
Consumer 数已等于分区数 → 增加分区数或优化 Consumer 处理逻辑

故障 3：磁盘写满

症状：Broker 日志报错 DiskFullException。

诊断：

# 1. 检查磁盘
df -h /data/kafka/
# /dev/sdb1  500G  495G  5M  99% /data/kafka/

# 2. 检查哪些 Topic 占空间多
du -sh /data/kafka/*/ | sort -rh | head -10

# 3. 紧急清理：降低保留时间
bin/kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics --entity-name large-topic \
  --alter --add-config retention.ms=3600000

预防：

设置 log.retention.bytes 作为硬限制
配置磁盘使用率告警（> 80%）
使用 kafka-log-dirs.sh 定期检查各 Broker 磁盘

故障 4：生产者收到 `NOT_LEADER_FOR_PARTITION`

症状：Producer 间歇性收到此错误，重试后恢复。

原因：正在发生 Leader 切换（Controller 选举新 Leader 期间 Producer 连到旧 Leader）。

分析：

# 检查 Controller 日志
grep "Leader election" /opt/kafka/logs/server.log | tail
# 如果频繁出现 → 检查是否有 Broker 不稳定

# 检查网络
netstat -s | grep retrans
# 大量重传说明网络不稳定

解决：

Producer 端配置合理的 retries 和 retry.backoff.ms
排查网络或 Broker 稳定性问题
使用 Cooperative Sticky 减少 Rebalance 导致的 Leader 切换

易错场景

易错 1：一上来就重启 Kafka

场景：消费堆积时第一反应是重启 Broker。

后果：重启触发 Leader 切换 → NOT_LEADER_FOR_PARTITION → Producer 重试 → 更多请求 → 集群负载反增。

正确做法：先诊断根因（Consumer 慢？分区倾斜？网络问题？），大部分故障不需要重启。

易错 2：修改 `unclean.leader.election.enable=true` 来"临时恢复可用性"

场景：ISR 全挂，分区不可用，紧急改为 true 恢复服务。

后果：选上数据落后的副本 → 数据永久丢失。权衡"可用性 vs 数据完整性"需要业务方确认，不应由运维单方面决定。

面试高频考点

Q：Kafka 集群出现"脑裂"怎么办？

A：

Kafka 的脑裂场景有两种：

Controller 脑裂：KRaft 模式下由 Raft 协议保证严格单一 Leader；ZK 模式下依赖 ZK 临时节点。真正的 Controller 脑裂在现代 Kafka 中极少发生。
Partition Leader 脑裂：旧 Leader 因网络分区被隔离，新 Leader 被选出。旧 Leader 恢复后：
- 旧 Leader 继续接收写入 → 数据不一致
- Kafka 的解决：Leader Epoch 机制。旧 Leader 恢复后发起的写入请求附带的 Epoch 已过期 → Broker 拒绝写入 → 旧 Leader 截断日志

操作：

如果确认发生脑裂：隔离网络不稳定的 Broker，等待 Controller 恢复一致性
检查 leader-epoch-checkpoint 文件确认 Epoch 推进正常