解读

面试官想考察的是：

1. 面对线上突增的消费延迟，能否在 5 分钟内给出“可回滚”的初步结论，而不是一口气把全链路监控全翻一遍。
2. 是否具备“分区级”视角：Kafka 的延迟一定是分区间不均衡的，先找“最慢分区”再定边界。
3. 是否能把“判断”与“止血”合二为一：如果是 Broker 侧问题，能否立刻给出应急参数；如果是 Consumer 侧问题，能否给出秒级扩容或降级方案。
4. 是否熟悉国内主流监控（阿里云 ARMS、腾讯云 TDMQ、自建 Prometheus+Grafana、滴滴 Logbook、美团 Mtrace）的字段含义，避免“背英文指标”而现场对不上中文控制台。

知识点

1. Kafka 延迟的三段拆解
   生产端耗时 → Broker 端排队耗时 → 消费端处理耗时
   只有第 2 段涨是 Broker 问题，第 3 段涨是 Consumer 问题。

2. 关键指标中文映射
   Records Lag Max/MaxLag 分区堆积
   Fetch Rate 拉取条数/秒
   Fetch Throttle Time 拉取被限流时长
   Request Queue Time 请求在 Broker 端排队时长
   ISR Shrinks 副本掉 ISR 次数

3. 国内云厂商特有字段
   阿里云“消息堆积量”= 分区 HW – Consumer Offset
   腾讯云“可消费消息数”= LogEndOffset – Consumer Offset
   华为云“消费落后时长”= 堆积量 ÷ 近 5 min 平均消费速率

4. 秒级定位三板斧
   ① 看“最慢分区”：MaxLag 分区是谁，是否集中在某几个 Broker 上。
   ② 看“Fetch 线程”：Consumer 日志里 fetch 响应耗时 >1 s 的占比。
   ③ 看“Broker 排队”：Request Queue Time 是否 >50 ms，或 ISR 是否频繁 Shrinks。

5. 应急开关
   Broker 侧：num.replica.fetchers、replica.socket.receive.buffer.bytes、log.flush.interval.messages
   Consumer 侧：max.poll.records、fetch.min.bytes、fetch.max.wait.ms、并发分区数

答案

线上出现消费延迟突增，按“三分钟三步法”快速定界：

第一步，30 秒看堆积分布
在 ARMS/TDMQ 控制台直接搜“消费组名称”，按分区排序，找到 MaxLag 最大的 3 个分区。
若 MaxLag 高的分区均匀散落在所有 Broker → 大概率 Consumer 能力不足；
若 MaxLag 高的分区全部落在同一台 Broker → 先怀疑 Broker 节点。

第二步，60 秒看 Consumer 日志
登录一台 Consumer 容器，grep “FetchResponse” | awk 打印 fetchLatencyMs。
如果 95% 分位 <200 ms，而堆积仍涨 → 说明拉取不慢，是处理慢，定位 Consumer 业务逻辑；
如果 95% 分位 >1 s，且日志里同时出现“Connection to Node XX timed out” → 网络或 Broker 排队。

第三步，90 秒看 Broker 队列
在 Prometheus 查 kafka_network_request_total{request=“FetchConsumer”,broker_id=“XX”} 与 kafka_request_queue_time_ms 的 99 分位。
若 Request Queue Time 突增到 >50 ms，且 ISR Shrinks 计数 +1 → Broker 侧磁盘或 PageCache 抖动，立即调大 num.io.threads 并降低 log.flush.interval.messages 临时止血；
若 Request Queue Time 平稳 → 回到 Consumer 侧，立刻扩容分区并发度或调大 max.poll.records 把拉取窗口撑满。

通过以上三步，可在 3 分钟内给出“是 Broker 还是 Consumer”的量化结论，并附带可执行的应急参数，满足国内一线互联网生产环境 SRE 要求。

拓展思考

1. 如果 MaxLag 高但 Consumer 的 fetchLatencyMs 与 Broker 的 Request Queue Time 都不高，要警惕“消息体突增”导致网络带宽打满，此时需查看云厂商的“出带宽/限流次数”指标。
2. 国内金融场景常开“消息轨迹”，可快速拿到单条消息的“生产时间→Broker 落盘时间→Consumer 收到时间”三段耗时，比看聚合指标更精准。
3. 双十一等大促前，建议把“分区级”告警阈值设为“动态基线”：用前 7 天同时段 95 分位做基准，避免静态阈值误报。
4. 如果判断为 Consumer 问题但无法立即扩容，可考虑“降级采样”：临时把非核心 Topic 的并发度让渡给核心 Topic，保障 SLA 不击穿。