Kafka百万级TPS源于绕开JVM瓶颈，依托顺序写磁盘、MMAP零拷贝、分区并行批量处理及轻量元数据设计，实现OS、存储与网络深度协同。
Kafka 能在 Java 环境下稳定支撑百万级 TPS，根本不在 JVM 本身多快，而在于它绕开了传统 IO 和内存瓶颈，把整个数据流转路径“贴着硬件特性”重新设计了一遍。Java 进程（Kafka Server）只是调度者和协调者，真正扛吞吐的是操作系统层+磁盘硬件的协同机制。
顺序写磁盘：用机械硬盘跑出 SSD 速度
普通数据库或 MQ 常因随机写放大延迟，Kafka 强制所有消息追加到 Partition 日志文件末尾——这是典型的顺序写。机械盘顺序写可达 100+ MB/s，SSD 更高；而随机写可能只有几百 KB/s。Kafka 的日志段（log segment）默认 1GB，写满自动滚动，始终维持单点追加，不 seek、不覆盖、不删中间数据。
- 每个 Partition 对应一个物理文件目录，消息按 offset 严格递增写入
- 操作系统页缓存（Page Cache）会自动缓存最近写入的磁盘页，读请求多数命中内存，不真刷盘
- 即使落盘，也是批量 flush（由 log.flush.interval.ms 或 sync 策略控制），不是每条都 fsync
MMAP + 零拷贝：减少数据在内核与用户空间之间搬运
Kafka 服务端用 MMAP 将日志文件直接映射进 JVM 进程的虚拟地址空间。Java 层调用 FileChannel.map() 创建内存映射，后续读写就像操作 byte[] 一样，内核自动完成磁盘 ↔ 内存同步，省掉 read()/write() 的多次 copy。
- Producer 写入时：网络数据从网卡 DMA 到内核缓冲区 → 直接 write() 到 mmap 区域 → 数据异步刷盘
- Consumer 读取时：Broker 调用 sendfile() 系统调用，让网卡 DMA 直接从页缓存读数据发出去，全程不经过 JVM 堆内存
- 避免了“内核缓冲区 → 用户空间缓冲区 → JVM 堆 → 网络发送缓冲区”的四次拷贝
分区并行 + 批量处理：把吞吐拆开压，再合起来发
Kafka 把 Topic 拆成多个 Partition，每个 Partition 是一个独立日志，可分布在不同 Broker 或磁盘上。Producer 和 Consumer 都能并发读写多个 Partition，天然水平扩展。
立即学习“Java免费学习笔记（深入）”；
- Producer 默认启用 batch.size（如 16KB）和 linger.ms（如 5ms），攒够一批再发，降低网络调用频次
- Broker 接收后不解析单条消息，而是以 RecordBatch 为单位存入日志，压缩（snappy/lz4/zstd）也在批次粒度做
- Consumer 拉取时也按批次返回，一次 fetch 可含数千条消息，减少 RPC 往返
轻量元数据 + 无状态 Broker：不把性能耗在协调上
Kafka 把路由、偏移量、消费者分组等元数据全交给 ZooKeeper（旧版）或 KRaft（新版本 3.3+）管理，Broker 自身不维护全局状态。每个 Broker 只管自己负责的 Partition 分片，不参与消息路由决策，也不做中心化转发。
- Producer 直连目标 Partition Leader，绕过 Broker 中转
- Consumer 自己管理 offset（可提交到 __consumer_offsets 主题），Broker 不保存消费进度
- 副本同步（ISR）采用异步拉取 + 高水位推进，不阻塞主写入路径
这些设计不是孤立起作用的，而是环环相扣：顺序写保障磁盘效率，MMAP 和零拷贝释放 CPU，分区和批量放大并行度，轻量元数据确保扩展不减速。Java 实现只是载体，真正的高吞吐来自对 OS、存储、网络三者的深度协同。
