题目：假设你收到告警，某个消费组消息堆积从 1000 涨到 100 万，你会按照什么步骤排查？请模拟一次线上排查过程。
难度：high
标签：practice/debug, mq/rocketmq, mq/kafka, architecture/resilience, network/debug, difficulty/high
评分：⭐⭐⭐☆☆（3/5）
从整个链路上来说，消息发生了堆积，要么是生产者大量生产了消息，要么是消费者出现了消费异常。先确认一下两边的情况，确认消息具体的一段时间内的增长情况，是否做了，产生了大量增长。其次确认一下消费者消费端的消费量是否正常。然后是因为生产者产生大量消息导致的堆积，还是因为消费者出现了异常，无法正常消费导致的消息堆积。然后确认了这个情况之后，再去根据得到的结果，如果是生产者。生产大量消息，这时候考虑进行把进行把消息转移，然后进行扩容消费者。如果是消费者端消费的能力出现了问题，检查消费者端到底出现了什么问题，是服务出现异常情况，是否需要重启，需要哪些异常处理。
优点：
不足：
kafka-consumer-groups.sh --describe、Kafka Manager、Lag 监控指标、GC 日志等补充（完整排查流程）：
核心考点定位：考察系统性排查能力——不是知识点的记忆，而是从"收到告警"到"定位根因"到"制定方案"的完整工程思维。
知识点拆解：
kafka-consumer-groups.sh --bootstrap-server ... --describe --group <group> 查看每个分区的 Current-Offset / Log-End-Offset / Lagmax.poll.records 太大、max.poll.interval.ms 超时）--to-latest 或修改 offset）从「确认现象」→「分场景定位」→「根因分类」→「分级方案」，构成完整排查链条。
考察方向：
kafka-consumer-groups.sh 参数、Kafka Manager / Prometheus 监控指标延伸递进的顺序排查流程（生产实战）：
kafka-consumer-groups.sh --describe --group <group> 看 Lag 分布延伸递进面试题：
session.timeout.ms 和 max.poll.interval.ms、减小 max.poll.records面试官您好，收到堆积告警后，我会按"确认现象 → 分场景定位 → 找根因 → 分级方案"这四步走。
第一步是确认现象。我用 kafka-consumer-groups.sh --describe --group <group> 看每个分区的 Lag 分布。堆积 100 万到底是均匀分布还是集中在某个分区，这决定了后续排查方向。同时看堆积增长速度，是线性还是指数增长，指数增长往往是正反馈问题。
第二步是分场景定位：
如果是堆积均匀增长，说明消费者整体处理慢，重点查 Consumer 侧：下游 DB 慢查询、外部 API 超时、线程池打满、JVM FullGC、业务逻辑死锁、幂等去重表锁竞争。同时看 Rebalance 频率，如果 Rebalance 频繁，整个组会周期性暂停消费。
如果是堆积集中在某个分区，重点查该分区：消息 Key 是否特殊、消息体是否异常大、消费逻辑是否有死锁、消费者是否被正确分配到该分区。
如果是堆积突然从 0 到 100 万，重点查：Producer 侧是否突发大量消息（下游积压、批量任务、重试风暴）、Consumer 组是否突然崩溃、Rebalance 是否触发。
第三步是根因分类：
Consumer 侧：下游依赖问题、JVM 问题（FullGC、OOM）、业务逻辑问题、配置问题（max.poll.records 太大）、网络问题。
Producer 侧：突发大量消息、重试风暴。
Kafka 集群侧：Broker 磁盘满、副本同步慢、Controller 频繁切换。
第四步是分级方案：
数据不能丢（P0）：扩容消费者（注意分区数上限，消费者数不能超分区数）、限流生产者、下游扩容或优化、消费端保证幂等。
可以延迟（P1）：降级消费逻辑、临时跳过非核心消息。
可以丢弃（P2）：跳过堆积消息（--to-latest 或修改 offset）。
这里有几个坑要注意：第一，消费者数超过分区数是无效的，扩容前先确认分区数；第二，Rebalance 期间整个组会暂停消费，几秒到几十秒的堆积是正常的；第三，堆积恢复时可能重复消费，消费端必须做幂等；第四，扩容分区会改变消息路由，需要评估对顺序性的影响。
日常还要做好堆积告警、自动化预案、定期演练，让问题在早期被发现。
题目：假设你收到告警，某个消费组消息堆积从 1000 涨到 100 万，你会按照什么步骤排查？请模拟一次线上排查过程。
难度：high
标签：practice/debug, mq/rocketmq, mq/kafka, architecture/resilience, network/debug
评分：⭐⭐⭐⭐☆（4/5）
练习次数：2
首先确认整个链路是怎么回事。我们以 Kafka 为例,整个消息的链路应该是,生产者生成->broker->消费者消费;
出现堆积主要可能性就只有两个,1 是生产者创建的消息出现波动创建了大量等消息,下有消费者消费能力没有能提高,这时候按原本消费的能力去消费，就产生了大量的堆积。
这里要处理的，就是消费者方面，要进行扩容也好，提升消费能力也好，主要的是要把消费能消费的能力提上来，快速的把这些消息消费掉。如果是有序的消息，就只能控制消费者了。的提升自身能力。如果是无序的消息，可以考虑把消息先转到另一个 Topic 上。然后再缓慢地进行分流处理。
2 是消费者出现问题,生产者的生产速度没有变动，但是消费者的消费能力出现大幅降低，导致原有的消息进行堆积。这时候要排查的是消费者为什么出现问题，是出现了业务侧的数据库能力异常，还是消费者本身的 ZVM 或者是其他的消费的整个消费者出现了卡顿。然后消费者是否出现了特殊的情况，比如大量的 GC，或者是网络中断之类的情况导致消息积压。这时候就要针对的处理消费者自身的问题，可以先把所有的 Topic 消息转移到一个新的消息 Topic 上，然后进行临时处理，然后去处理消费者上的问题。处理好之后，恢复正常的消费能力，再慢慢的消费积压的消息。从新的 Topic，原来的备用的 Topic 上，把它的积压的消息消费掉，以及顺序的消费新的消息。
要区分是生产者还是消费者的问题，可以通过监控看生产者跟消费者的 TPS 具体是怎么样的。如果生产者的 TPS 生产特别变动特别大，提高特别高，那就是生产端出现了大的波峰的请求。如果是消费者的 TPS 变低了，那就是消费者自身出现了问题，对应的再进行上述的排查和处理
优点：
不足：
kafka-consumer-groups.sh --describe 看每个分区的 Lag（均匀 vs 集中）max.poll.records、max.poll.interval.ms、session.timeout.ms补充：
max.poll.records（单次 poll 拉取数）、max.poll.interval.ms（超时未 poll 会被踢出消费组）、session.timeout.ms（心跳超时）ℹ️ 完整讲解见上方首次记录（2026-09-22）