出现消息积压时应该如何处理？

提示

题眼： 加速处理，或抛弃

重要

参考答案：

（三种情况）

一般情况下，出现消息堆积有两种情况。第一种是消费速率太低导致的积压，这种情况下，监控上应该是所有分区的消息积压很平均，都慢。这种是比较好处理，只需要排查后续的业务操作，是否出现超时，慢查询这种问题，或者将原本的逐条写入，改成批量写入，提高消息速率就可以。实在不行，还可以看下是否能扩容，增加几个消费端，就好了。

第二种，比较麻烦，不过不常见，我遇见的很少。就是出现某些热点数据，然后打到同一个分区了，这种的话，一般只能是拉一个新的 topic 做紧急转发（kafka 的消息落到分区后，再扩容，不会影响历史数据，因此，扩容不一定能搞定）。不过这种情况很少见，一般还是以预防为主，因为拉新的 topic 成本太高了，还要重新测试上下游。

还有一种比较特殊的情况，就是消费服务挂了，重新拉起后，如何处理历史消息积压的。这个的话，主要看服务的紧急度和消息的重要性。如果服务不那么紧急，消息不重要，可以设置偏移量，直接舍弃掉这部分数据，从最新的地方开始消费。如果说，比较重要，可以临时增加一些消费端，或者干脆保存一份，异步慢慢处理，先把服务拉起来。

我接触过的场景里，实际处理这个问题还是比较麻烦的。不仅有积压，还有持续的消息写入，所以扩容的时候，也要算一下当前的生产效率，然后评估扩容的数量和效率。再一开始设计服务的时候，我们 leader 就让按照 1:1.5 或者 2 倍以上的效率配置，让消费者比生产者多一些，避免出现问题。