kafka

7次阅读

作为一名资深 Java 开发，面试 Kafka 时，面试官通常不会只问你“什么是 Topic”，而是会深入到底层磁盘 IO、高可用机制和分布式一致性。

以下我为你梳理了 Kafka 最常考的“夺命连环问”，分为四个维度：

这是必考题。Kafka 能够处理每秒百万级消息，主要靠这四大神技：

顺序读写磁盘：磁盘随机读写很慢，但顺序读写（Append Only）的性能接近内存。Kafka 像写日志一样只在末尾追加数据。
Page Cache（页缓存）：Kafka 极度依赖操作系统的缓存，而不是自己在 JVM 里搞缓存。这样即使 Kafka 重启，缓存依然在，且避免了 GC 开销。
零拷贝（Zero Copy）：
- 原理：利用 Linux 的 sendfile 系统调用。
- 过程：数据直接从“磁盘文件”通过内核缓冲区发送到“网卡”，不需要经过“用户态”的内存拷贝。
分区分段（Partition & Segment）：并发处理能力，将大文件拆分成小文件，方便检索和清理。

这是一个闭环问题，需要从三个角色来答：

生产者（Producer）：
- acks 配置：
  - 0：发了就不管（性能最高，最不可靠）。
  - 1：Leader 收到就返回（默认）。
  - -1 / all：所有 ISR 副本都收到才返回（最可靠）。
- 重试机制：设置 retries 避免网络抖动导致丢包。
Broker（服务端）：
- 多副本机制：设置 replication.factor >= 3。
- min.insync.replicas：配合 acks=all，确保至少有 N 个副本写入成功。
消费者（Consumer）：
- 关闭自动提交：改为手动提交 Offset。先消费业务逻辑，再提交位移。

原因：消费者处理完了，但没来得及提交 Offset 就重启了。
解决：业务端做幂等性设计。利用数据库唯一索引、Redis setnx，或者 Kafka 0.11 之后自带的 幂等性生产者（Idempotent Producer）。

核心逻辑：Kafka 只能保证 Partition 内部有序。
实现：
1. 发送时指定相同的 Routing Key，确保相关的消息进入同一个 Partition。
2. 消费者端使用单线程处理，或者按 Key 进行内存队列分发。

这是区分资深与初级的关键：

AR (Assigned Replicas)：分区中的所有副本。
ISR (In-Sync Replicas)：与 Leader 保持同步的副本列表（包括 Leader 自己）。只有在 ISR 里的副本才有资格被选举为新 Leader。
OSR (Out-of-Sync Replicas)：同步落后太多的副本。
关系：AR = ISR + OSR。

定义：当消费者组里有成员加入或退出时，Partition 会被重新分配给消费者。
痛点：Rebalance 期间，整个 Consumer Group 会 STW（Stop The World），无法消费。
如何优化：
- 合理设置 session.timeout.ms（心跳超时）。
- 避免消费者逻辑过重导致处理时间超过 max.poll.interval.ms。

面试官可能会问：“为什么 Kafka 3.0 开始推行 KRaft 协议去掉 Zookeeper？”

答案：
1. 元数据压力：ZK 无法承载上万个 Partition 的元数据更新。
2. 选举慢：Leader 挂了后，依赖 ZK 选举太慢。
3. 运维简化：不再需要维护两套分布式系统。

对于你这种想转型但又不丢技术底子的人来说，Kafka 的分布式设计思想（如分段存储、位移管理）其实可以应用到很多非编程的架构设计中。

既然聊到了消息队列，你想看看如何结合 Spring Boot 事务和 Kafka 事务，实现“发消息”与“数据库更新”的强一致性吗？

正文完

发表至：技术

近一天内

0

转载说明：除特殊说明外本站文章皆由CC-4.0协议发布，转载请注明出处。

mq

1. 为什么 Kafka 性能这么高？（吞吐量之王）