Kafka 为什么能做到高吞吐？顺序写、零拷贝、页缓存、批量处理怎么配合？

考察点

这题考系统功底而不是 Kafka 本身，面试官想确认你理解操作系统层面的 I/O 知识。四个机制每个都要能讲出"省了哪次拷贝/哪次寻道/哪次系统调用"，只说名词是不过关的。追问常落在：零拷贝具体省了几次拷贝几次上下文切换、page cache 宕机丢不丢数据、批量参数怎么调。

参考答案

先破除一个直觉：磁盘不一定慢

很多人以为消息队列写磁盘必然慢，Kafka 单机轻松扛几十万 QPS 的写，靠的不是绕过磁盘，而是把磁盘的用法优化到极致。核心思路一句话：所有数据都走顺序路径，所有拷贝能省则省，所有请求能攒批就攒批。

顺序追加写：把随机 I/O 变成顺序 I/O

Kafka 的消息日志是 append-only 的：每个分区的日志文件（分段成多个 Segment）只往后追加，不原地修改、不随机插入。机械盘上顺序写的吞吐可以到几百 MB/s，和随机写（几十到几百 IOPS，折算可能只有几 MB/s）差两三个数量级；这个差距大到"顺序写磁盘"比"随机写内存"都快。

索引也是稀疏索引（offset 索引 + 时间戳索引），二分查找定位到 Segment 内的某个区域后顺序扫，整体还是顺序读的模式。删除消息靠 Segment 整段过期或 compact，同样不产生随机写。

Page Cache：让内核替你管理内存

Kafka 自己不堆 JVM 堆内缓存（堆大 GC 就难受，这是和很多 Java 系统不同的设计决策），消息写入先进操作系统的 Page Cache，由内核决定何时刷盘。好处有三层：

1. 读写都命中内存——消费者读的消息大概率刚写入还在 Page Cache 里，根本不用读盘。
2. Broker 进程重启缓存不丢（缓存属于内核不属于进程）。
3. JVM 堆可以配得很小（通常几个 G），GC 压力小，机器剩余内存全留给 Page Cache。

代价是写入只到 Page Cache 不算物理落盘，单机断电会丢最后一段。Kafka 的对策是副本冗余而不是强制刷盘——这个问题在 acks 那题里展开过，这里点出设计取舍即可。

零拷贝：sendfile 省掉四次拷贝里的三次

消费拉取是 Kafka 数据流出的大头。传统 read+write 方式，数据从磁盘到网卡要走：磁盘 → 内核缓冲区 → 用户态缓冲区 → socket 内核缓冲区 → 网卡，共 4 次拷贝、4 次用户态/内核态上下文切换。

Kafka 用 sendfile（Java 层是 FileChannel.transferTo）：磁盘 → 内核缓冲区 → 网卡（支持 scatter-gather 的网卡甚至不用经 socket 缓冲区），数据全程不进入用户态，2 次拷贝、2 次上下文切换。消息在 Kafka 里不需要被 Broker 进程"看懂"，格式原样透传，这是零拷贝能成立的前提。

批量处理：贯穿客户端和协议的最后一环

Producer 端按分区攒批：batch.size（默认 16KB）和 linger.ms（默认 0，生产建议调到 5-100ms）控制批次大小和等待时间，一个 batch 一次网络请求，还整体做压缩（lz4/zstd，压缩在 Producer 端做、日志里保持压缩态存储、Consumer 端解压，Broker 全程不碰）。Consumer 的 Fetch 请求也是批量拉，且带"凑不够 min.bytes 就等到 fetch.max.wait.ms"的攒批逻辑。

批量的收益是数量级的：单条 1KB 的消息逐条发，网络开销（TCP 头、请求往返）远超有效载荷；攒成 16KB 的批再压缩，IOPS 降一个数量级不止。

一句收拢

高吞吐不是某一个机制的功劳：顺序写让磁盘不再是瓶颈，Page Cache 让热数据常驻内存，零拷贝让发送路径短到极致，批量把网络和 CPU 开销摊薄。四个机制拼起来，Kafka 才把"基于磁盘的日志"做成了"接近内存队列"的吞吐。

可能的追问

• Page Cache 里的数据宕机丢了怎么办？ 靠副本：acks=all + ISR 确认时，数据已到多个副本的 Page Cache，单机断电不影响整体。这也是 Kafka 不鼓励配 flush 参数的原因。
• 为什么压缩放在 Producer 端做？ 摊到客户端节省 Broker CPU，且日志以压缩态存储，Broker 转发不用解压再压缩；zstd 在压缩比和速度上平衡好，生产常用。
• 消息大到 10MB 级，这些机制还成立吗？ 批量收益下降、Page Cache 压力大、单批拉取变慢，大消息是 Kafka 的弱项，常见做法是消息体瘦身（存引用，大对象放对象存储）。