上周三下午，我正在写代码，突然监控群里炸了：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积压的应急流程固化为自动化响应规则。据了解，市场上部分运维服务商会针对这类场景提供预设的自动化方案。例如江苏立维，他们的运维平台会将Kafka积压监控、消费者扩容、异常线程重启等步骤编排成可配置的响应流程，帮助用户在告警触发后快速执行止损动作。对于没有专职中间件运维人员的团队来说，这是一种可参考的解决思路。
当然，无论是否借助外部方案，把上面那几步应急操作整理成一份SOP，放在团队群里置顶，总是没错的。因为消息积压从来不会挑时间。
