Kafka 零拷贝为什么能提升吞吐？
面试怎么回答
传统文件传输会在 Page Cache、用户态缓冲区和 Socket 之间多次复制。Kafka 采用统一批量日志格式，能够利用 sendfile 等系统能力，让 Page Cache 中的数据更直接进入网络路径，减少用户态拷贝、系统调用和 CPU 消耗。它还受益于顺序写和 Page Cache 复用，但 TLS、消息改写和解压可能限制这条路径。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
Kafka 读取磁盘数据后，为什么不先交给 Broker 业务代码再发给消费者？
对大量顺序日志来说，多一次用户态拷贝就意味着更多 CPU、内存带宽和上下文切换。
零拷贝通过操作系统能力让 Page Cache 中的数据更直接地发送到 Socket，减少用户态往返和数据复制。
传统路径的额外开销
常规文件发送需要数据从磁盘进入内核 Page Cache，再复制到用户态缓冲区，随后写回内核 Socket 缓冲区。中间包含多次复制和系统调用。
sendfile 减少用户态往返
Kafka 的日志格式允许 Broker 不必重新编码消息，操作系统可以把 Page Cache 数据直接送往网络路径，减少进入用户态和再次复制。
Page Cache 同样关键
热点日志可直接从 Page Cache 服务多个消费者，Broker 不需要自己维护同等规模的对象缓存。顺序写与批量传输进一步提高磁盘和网络效率。
零拷贝也有边界
TLS、需要修改消息内容、解压重编码或某些传输路径可能无法完全使用 sendfile。性能还取决于批量、压缩、网络和消费者追赶状态，不能把高吞吐全部归因于一个机制。
为什么不能只回答概念？
“浅答案：sendfile 让磁盘直接连上网卡”之所以常见，是因为它在理想数据和单次执行里往往说得通。但生产环境会加入数据规模、异常值、并发、版本、失败重试和下游口径，这些条件一变化，只记住术语就很容易给出错误结论。
所以我会把 传统路径的额外开销、sendfile 减少用户态往返、Page Cache 同样关键、零拷贝也有边界 串成一条完整链路。最终判断标准不是某个函数或配置是否出现，而是能否稳定得到可解释、可验证、可恢复的业务结果。
落地时我会检查什么？
- 输入边界：确认数据范围、时间口径、主键和异常值是否符合假设。
- 执行过程：观察分区、并行度、状态、Shuffle 或资源变化，验证方案是否真正生效。
- 输出结果：用行数、唯一性、关键指标和样本明细证明结果正确，而不是只看任务成功。
- 失败恢复：说明重跑、回滚、版本兼容和责任人，避免一次成功后无人维护。
这些检查不一定全部写进一条 SQL 或一个任务，但面试时能主动补充，说明你回答的不是背诵题，而是在描述一套可上线的工程方案。
一个典型场景
一个集群启用加密传输后 CPU 明显上升，团队以为磁盘出现瓶颈。实际是数据需要经过用户态 TLS 处理，原有 sendfile 路径无法照常使用。扩容只能缓解，最终还需要结合安全要求、批量压缩和网络容量重新评估。
零拷贝减少数据搬运，但不会消除加密、压缩和网络成本。