百度面试官：Kafka 百万消息积压如何处理？

不得不说，程序员面试的水深有时候比大西洋还深。这不，今天咱聊一个经典问题：Kafka 消息积压的应对方法。想想面试官问你，“Kafka 消息积压到百万条，你怎么处理？”是不是顿时脑袋一片空白？别急，今天我们一起把这个问题掰扯清楚，让你下次面试稳得住！

Kafka 消息积压是个啥？

先别急着头脑风暴，我们得搞清楚 Kafka 消息积压到底是怎么一回事。Kafka 本质上是个分布式消息队列，消息的生产和消费各自独立。如果消费者处理消息速度跟不上生产者的发送速度，消息就会越积越多，直到 Broker（Kafka 的消息存储节点）顶不住。

就像公司年会吃自助餐，厨师拼命上菜，但服务员摆不上桌，菜就堆在厨房门口，后果你懂的：锅端不动了！🙃

面试官的套路问题

当面试官问你这个问题时，TA 可能在考察你几个方面：

1. Kafka 的核心概念和原理：你是否真的懂 Kafka。
2. 问题排查能力：能不能快速定位问题根源。
3. 解决方案的合理性：方案是否既高效又实际。

消息积压咋处理？

OK，接下来，我们逐步拆解这个问题。毕竟搞程序的，都信奉一句话：拆得够细，解决够快。

1. 确认积压的规模和时间

第一步，先别慌，了解积压规模是关键：

• 消息总量：百万条消息是单个分区还是整个 Topic 的总量？
• 积压时间：是刚开始积压还是已经持续了很久？

通过 Kafka 提供的工具（比如 kafka-consumer-groups.sh）查看消费组的 Lag（消费者落后生产者的消息数）。命令如下：

kafka-consumer-groups.sh --bootstrap-server <broker-url> --describe --group <consumer-group>

输出会显示 Lag，Lag 越大，积压越严重。

2. 分析原因

消息积压的原因通常分两类：

• 生产端问题：生产者发送速率暴增，比如应用突然大流量。
• 消费端问题：消费者处理能力不足，比如消费逻辑太复杂。

记住，Kafka 处理积压和炒菜一样，不能一味让厨师上菜（生产端增压），也不能光换服务员（消费端提速），两边都得看看。

3. 解决方案

既然问题找到，那解决方案就能逐步展开。

方案一：临时扩容消费者

简单粗暴：增加消费者实例。如果积压的 Topic 有多个分区，可以通过增加消费者实例让消费组扩展，分区和消费者之间的处理能力更平衡。

代码示例（Spring Kafka）：

@KafkaListener(topics = "example-topic", groupId = "example-group", concurrency = "5")
public void listen(String message) {
    // 消费消息的逻辑
    System.out.println("Received: " + message);
}

上面的代码中，concurrency 参数设置为 5，代表开启 5 个消费者线程，从而提升消费能力。但注意，消费者数量不能超过分区数，否则多余的消费者会闲置。

方案二：临时提高消费端吞吐量

如果消费端逻辑较重，比如需要操作数据库，可以通过 批量消费 提升吞吐量。

示例代码：

@KafkaListener(topics = "example-topic", groupId = "example-group", containerFactory = "batchFactory")
public void listen(List<String> messages) {
    // 批量处理消息
    System.out.println("Received batch: " + messages.size());
}

对应的配置：

@Bean
public ConcurrentKafkaListenerContainerFactory<String, String> batchFactory() {
    ConcurrentKafkaListenerContainerFactory<String, String> factory =
            new ConcurrentKafkaListenerContainerFactory<>();
    factory.setConsumerFactory(consumerFactory());
    factory.setBatchListener(true); // 开启批量消费
    return factory;
}

通过批量处理减少单条消息的 IO 操作，可以显著提升消费效率。

方案三：增加分区数

如果当前的分区数较少（比如只有 2 个分区，而消费者组里已经有 5 个消费者），可以通过增加分区数来提升吞吐能力。

kafka-topics.sh --alter --topic example-topic --partitions 10 --bootstrap-server <broker-url>

增加分区后，需要确保生产者和消费者的分区分配逻辑保持一致，否则可能出现消息分散不均的问题。

方案四：消息过期清理

如果积压的消息是老旧的、已经无关紧要的，可以通过修改 log.retention 参数设置消息的过期策略，让 Kafka 自动清理：

kafka-configs.sh --alter --entity-type topics --entity-name example-topic \
--add-config retention.ms=600000 # 消息保留10分钟

这样可以快速释放 Broker 的存储压力，但注意，别手抖把需要的消息清了！

方案五：流量限制

如果积压是因为生产端速率过高，可以通过限流手段（比如设置 Producer 的 acks 参数）来降低发送速度。

示例代码：

Properties props = new Properties();
props.put("acks", "all"); // 确保消息确认，提高可靠性，但会降低发送速率
props.put("linger.ms", 10); // 延迟发送，提高批量效率

高手进阶：分布式问题的应对思路

除了以上常规操作，如果你想秀一波，还可以聊聊更高阶的优化思路：

1. 调整 Kafka Broker 参数：增加 num.network.threads 和 num.io.threads，提升 Broker 的网络和 IO 处理能力。
2. 使用流式处理框架：引入 Kafka Streams 或 Flink，对数据进行实时处理，分流压力。
3. 架构优化：通过拆分 Topic 或分布式存储进一步扩展 Kafka 的承载能力。

总结

面试官的问题其实不难，难的是在紧张的面试中理清思路。关键是记住三步：排查问题 → 分清责任 → 选择方案。别忘了加点调侃，比如说：

“面试官：怎么解决百万积压？

我：跟老板汇报，然后提申请买 10 台新机器，再加 20 个消费者，老板同意了，这问题就解决了！🤣

最后祝大家在面试中一骑绝尘，KO 所有 Kafka 面试题！💪

-END-

以上，就是今天的分享了，看完文章记得右下角给何老师点赞，也欢迎在评论区写下你的留言。