上周三下午，我正在写代码，突然监控群里炸了：Kafka 某个消费组的 Lag 飙到了 20 多万。紧接着，用户那边的订单状态开始不同步，客诉量蹭蹭往上涨。看到那个数字的时候我脑子确实嗡了一下，但很就让自己冷静下来。下面就是我那天真实干的几件事，按顺序写的，希望能给你一点参考。
第一件：先看看到底积压了多少，谁在用这些数据
我连上服务器，敲了个命令：
kafka-consumer-groups --bootstrap-server 地址 --group 消费组名 --describe
重点看 LAG 那一列。发现好几个分区都积压了几万条，而且还在持续涨，说明消费速度确实跟不上生产速度。
同时我赶紧问了产品一句：这个 Topic 里的数据影响到哪些页面？答曰：订单同步、物流状态、用户积分。那没办法，必须马上止血。
第二件：扩容消费者，这是最快方法
我们的消费者是跑在 K8s 上的。我直接去把副本数从 3 个扩到 10 个。敢这么干是因为我们的分区数本来就大于 10，新增的消费者不会闲着。
同时顺手改了一个配置：max.poll.records 从 500 降到 100。因为每条消息处理时间变长了，单次拉太多容易超时，消费者会被踢出群组，反而更乱。
扩完之后大概过了三分钟，Lag 的增速明显慢下来了，但没有降下去。说明光是加机器还不够。
第三件：发现每条消息处理都变慢了
我翻了翻日志，发现一条消息原本 10 毫秒就处理完，现在要 800 毫秒。再往下查，原来是下游的 Redis 突然变慢了------有个大 key 被频繁读取，导致 Redis CPU 飙高。
这就很尴尬，代码层面没法立刻优化 Redis。我想了个办法：把消息里写 Redis 的那部分逻辑先注释掉，只写数据库和发通知。日志和统计暂时落盘，等后面再补偿。
重启消费者之后，Lag 肉眼可见地往下掉。业务终于恢复正常。
第四件：等积压清完找根因
那天晚上我加班到凌晨两点，把 Redis 的慢查询日志扒了一遍，发现是一个同事上周上线的缓存预热逻辑写了个循环，把几万个 key 一次性全读了一遍。改掉之后，消费速度恢复到了原来的水平。
另外还补了两个东西：一是给消费组 Lag 加了一个电话告警，超过 1 万条就打给值班手机；二是在运维平台配置了一个自动化规则------Lag 持续 5 分钟超过阈值，自动增加消费者副本。
Kafka 积压这种事，只要你用了消息队列，早晚会遇到。关键是要看你有没有准备。
现在回头看，最管用的其实不是那些花哨的工具，而是两样东西：一个是看得清楚的监控------你得一眼知道哪个消费组慢了、慢在哪个分区；另一个是能自动干活的脚本------比如发现 Lag 涨了就自动扩消费者，不用人半夜爬起来敲命令。
我后来也了解了一下，像江苏立维那边做运维服务的，他们会把这种场景做成现成的"剧本"：监控到 Kafka 积压超过阈值，自动去查消费者数量、判断要不要扩容、甚至自动重启卡住的线程。对于没有专职中间件运维的团队来说，这种"开箱即用"的能力确实能省不少事。
不过不管用不用第三方，至少要把上面那几步写成一个 SOP，放在群里置顶。因为消息积压从来不会挑时间。