Kafka 常见故障排查路径

真实症状1：Consumer Lag持续升高

排查路径 1. kafka-consumer-groups.sh --describe 确认LAG真实是持续增长还是短暂冲高 2. 持续增长 → 查consumer自己的处理速度(是否有慢查询、外部API调用) 3. 短暂冲高 → 通常是consumer刚重启在追历史数据，或者生产端突发流量

本系列《Lag 很高时，问题可能发生在哪》真实制造过这个场景：consumer处理速度只有生产速度的1/3，LAG真实在18秒内从5611涨到30398，持续不收敛——这种曲线形态本身就是诊断结论，不需要更多猜测。

真实症状2：某个客户端的请求突然普遍变慢

排查路径 1. kafka-configs.sh --describe --entity-type clients --entity-name X 检查是否配了quota 2. 有quota → 对照《Kafka Quotas》一文，延迟暴涨(本系列真实测出33倍)是quota生效的典型特征 3. 没有quota → 继续查网络、broker负载

《Kafka Quotas》那篇真实测出配额生效后平均延迟从782毫秒暴涨到25944毫秒——如果只看到"某个client延迟特别高，其它client正常"，第一反应应该是查这个client有没有被配置了quota，而不是怀疑整个集群出了问题。

真实症状3：集群操作(建topic、发消息)卡住十几秒

排查路径 1. kafka-metadata-quorum.sh describe --status 检查controller quorum是否刚发生过切换 2. 检查是否有broker刚好挂掉——broker.session.timeout.ms默认9秒，加上客户端重试退避，端到端能拖到约11秒 3. 排除以上两点，再查网络分区或者磁盘IO异常

《Controller 故障时集群发生什么》真实测出：哪怕受影响的只是集群里一个broker、一个分区，客户端感知到的中断时间也真实能到11秒左右——这不是bug，是broker.session.timeout.ms这个真实的心跳超时机制决定的。遇到"卡了十几秒然后自己恢复"这种模式，先别急着怀疑网络或者代码逻辑，大概率是某个broker真实经历了一次故障和恢复。

分步演示：三种真实症状对应的排查路径

每一步都指向本系列前面真实跑出来的具体实验和数字。

每条排查路径背后都是本系列真实验证过的具体数字

这一步对应的真实症状

参考与说明

本文汇总本系列前面《Lag 很高时，问题可能发生在哪》《Kafka Quotas》《Controller 故障时集群发生什么》三篇的真实实验数据，构建成排查路径，没有引入新的实验。
没有验证：真实生产环境里多个症状同时发生的复合故障场景；网络分区(不同于本系列反复用的进程kill)这类更难复现的故障模式。

下一篇 · KAFKA 内部原理 71

Schema Registry：消息结构如何演进