Kafka能扛住百万级TPS，靠的是顺序写磁盘、页缓存、零拷贝、分区并行、批量处理、轻量元数据等底层优化设计，而非堆硬件。
Kafka能扛住百万级TPS，不是靠堆硬件，而是整套设计从底层就为“快”而生。它不追求单点极致，而是用简单、可预测、贴近硬件特性的思路，把吞吐量稳稳托住。
顺序写磁盘 + 页缓存，绕过内存瓶颈
传统认知里磁盘慢，但Kafka只做一件事：永远追加（append-only）。消息写入就是往日志文件末尾顺序追加，跳过了随机寻址的开销。实测顺序写盘可达300MB/s以上，接近内存随机写速度。
同时，Kafka完全依赖操作系统的页缓存（Page Cache）——消息先落盘，但读取时直接从内存映射的页缓存走，避免用户态拷贝；消费者拉取时，数据从页缓存经零拷贝直达网卡，省掉2次CPU搬运和2次上下文切换。
- 不自己管理JVM堆内存，规避GC抖动和内存泄漏风险
- 利用局部性原理，预读机制让连续读更高效
- 即使断电，只要刷盘策略合理（如log.flush.interval.ms=1000），数据依然可靠
分区（Partition）驱动并行，天然支持水平扩展
Topic被切分成多个Partition，每个Partition是独立的有序日志，可分布在不同Broker上。这是Kafka吞吐可线性增长的核心。
- 生产者按Key哈希或轮询发到不同Partition，写入完全并行
- 消费者组内多个Consumer各自消费不同Partition，互不阻塞
- 分区数≈CPU核数×2 是常见调优起点，既压满IO又避免过多小文件
批量处理 + 零拷贝 + 压缩，榨干每比特效率
单条消息传输太“贵”，Kafka全程以Batch为单位运作：
- Producer端：batch.size=16KB + linger.ms=5ms，攒够就发，减少网络往返
- Broker端：接收后暂存内存，再批量刷盘，降低I/O频率
- Consumer端：fetch.min.bytes=1 + fetch.max.wait.ms=500，主动拉取一批，而非被动等推送
- 压缩选snappy或lz4，批压缩比高，网络和磁盘节省50%~70%
- sendfile系统调用实现零拷贝，数据从磁盘→网卡直通，不进应用层
轻量元数据 + 无状态Broker，降低协调开销
Kafka把复杂逻辑尽量下沉：
- Broker本身无状态，不保存消费进度；offset由Consumer自己提交到__consumer_offsets Topic
- Topic/Partition/Leader分布等元数据由ZooKeeper（或KRaft）集中管理，Broker只做数据转发
- 稀疏索引（.index文件每4KB一条）加速Offset查找，不拖慢读写主路径
- 副本同步走Follower主动拉取，Leader无推送压力，集群更稳定
基本上就这些。没有黑魔法，全是把已知原理用到极致：顺序IO、批量、缓存、并行、精简。它不试图解决所有问题，只专注把“海量数据管道”这件事做到最稳、最快、最省。
