Kafka 高吞吐消息链路常见面试问题及详细解答

1. Kafka 为什么适合海量数据入口？

Kafka 适合海量数据入口，是因为它把数据写入和数据处理解耦了。

它通过分区实现并行，通过顺序追加日志提升写入吞吐，通过副本提高可靠性，通过 offset 支持回放和恢复，通过消费组支持横向扩展。

面试加分表达：

Kafka 不只是消息队列，它还是可回放的分布式日志系统。

2. 为什么 Kafka 要做分区？

分区是 Kafka 扩展吞吐和并行度的基本单位。

同一分区内消息有序，不同分区之间不保证全局顺序。

分区数太少，并行度不够；分区数太多，管理成本和 Rebalance 成本会上升。

分区设计要结合目标吞吐、消费端并行度、顺序性要求和未来扩容空间。

3. batch.size 和 linger.ms 是干什么的？

batch.size 控制每个批次能装多少字节。

linger.ms 控制最多等多久再发。

二者的目标都是提高吞吐、降低网络往返次数，但会引入一点发送延迟。

面试表达：

我会把 batch.size 和 linger.ms 视为吞吐与延迟之间的平衡参数。海量日志场景通常适合适度批量和适度等待，既保证吞吐，也别把实时性拖得太差。

4. acks=all 为什么更可靠？

acks=all 要求生产者等待 ISR 中满足条件的副本确认后才认为写入成功。

这样可以降低 leader 挂掉后消息丢失的概率。

代价是延迟更高，写入更慢。

注意：acks=all 不等于绝对不丢数据，还要看副本因子、ISR 健康、broker 稳定性和消费端 offset 提交。

5. 什么是幂等生产者？

幂等生产者通过 producerId 和 sequence 来识别重复写入。

它主要解决网络重试、超时重发带来的重复写入问题。

面试重点：

幂等生产者主要解决生产端重复写，不能替代消费端幂等和 Sink 幂等。

6. Kafka 的消费组是怎么工作的？

Consumer Group 允许多个消费者共同消费一个 topic。

同一个组内，一个分区同一时刻通常只会分配给一个消费者，这样可以避免重复消费同一分区的消息。

当成员增加或减少时，会触发 rebalance。

7. offset 应该什么时候提交？

最安全的方式是"先处理，后提交"。

如果先提交 offset，再处理业务，中途失败就会造成数据丢失。

如果处理后不提交，就可能重复消费。

所以工程上一般要配合业务幂等、事务性写入、去重表、重试和补偿机制。

8. Kafka 中的重复消费怎么处理？

Kafka 默认更偏向至少一次语义。

要应对重复消费，可以做业务幂等、去重表、事件唯一 ID、幂等写入、事务或两阶段提交。

面试表达：

我不会假设消息只会消费一次，而是默认可能重复，所以下游一定要做幂等。

9. 如何判断 Kafka lag？

lag 就是"还落后多少消息没处理"。

它通常可以理解为：

logEndOffset - committedOffset - 1

lag 持续上升，说明消费速度跟不上生产速度，可能要从消费者并行度、下游写入、反压、Topic 分区数和资源配置排查。

10. 为什么要有死信队列？

死信队列用于承接重试多次仍失败的消息。

它的价值是把坏消息与正常主链路隔离开，避免一条脏数据拖垮整个消费组。

视角：

DLT 不是可选项，是高可靠消息链路的必备兜底。

11. Kafka 怎么保证消息顺序？

Kafka 只能保证单分区内有序，不能天然保证全局有序。

如果业务需要实体级顺序，就要让同一实体 key 进入同一分区，例如 userId、orderId、deviceId。

正确说法是：

Kafka 保证的是分区内顺序，不保证全局顺序。

12. 生产者参数怎么选？

常见思路是：

1. acks=all：高可靠场景优先。
2. enable.idempotence=true：尽量开启。
3. batch.size：按吞吐调。
4. linger.ms：按实时性调。
5. compression.type：日志类数据常适合压缩。

面试表达：

我会先从可靠性出发，再做吞吐优化。高吞吐场景一般会使用批量发送、压缩和幂等生产者；如果业务对延迟极敏感，就要谨慎调 linger.ms，不要为了吞吐把实时性拖太低。

13. 发生 Rebalance 时要注意什么？

Rebalance 会导致分区重新分配，短时间内消费者可能暂停、重新拉取、重新提交 offset。

工程上要注意消费处理可中断、offset 提交稳定、下游写入幂等，并避免频繁扩缩容。

14. 如何从 0 到 1 设计 Kafka 消息链路？

我会按下面顺序设计：

1. 明确业务 key 和顺序要求。
2. 评估峰值吞吐和分区数。
3. 设计 ack、幂等和重试策略。
4. 设计消费组和 offset 提交策略。
5. 设计 lag 监控和告警。
6. 设计 DLT 和补偿链路。
7. 做容量压测和故障演练。

15. 面试时怎么总结 Kafka？

推荐回答：

Kafka 是海量数据链路的高吞吐入口。它通过 partition 做并行，通过顺序日志做高性能写入，通过 replica 和 ISR 做可靠性，通过 consumer group 和 offset 管理消费进度，通过幂等和事务降低重复风险，通过 lag、rebalance 和 DLT 做工程治理。
如果我来负责团队，我会先把 topic 规范、分区设计、容量评估、监控告警和死信补偿流程建立起来，再逐步优化吞吐和稳定性。