Kafka 敢把消息写进磁盘，是因为它避开了磁盘最慢的用法

Mon, 29 Jun 2026 18:02:16 +0800

日志量一上来，消息队列先扛不住。

很多团队的第一反应很自然：换 SSD，加 broker，调 batch size，甚至开始怀疑是不是 Kafka 参数没配对。

但吞吐上不去，有时候不是机器不够好。是数据一路都在走慢路：小块写、随机查、反复序列化，从应用层读出来，再拷进 socket，CPU 和 GC 跟着一起烧。

Kafka 最容易被误解的地方就在这里。

它不是让磁盘突然变快了，也不是靠 zero-copy 一个神技把所有问题抹掉。Kafka 真正做对的，是从一开始就把数据路径设计成硬件和操作系统擅长的形状。

顺序，大块，少拷贝。

这才是 Kafka 高吞吐的底层味道。

先把“快”说清楚：Kafka 快，主要快在吞吐

讨论 Kafka 为什么快，先别急着背 partition、ISR、replica、controller。

更应该先问一句：这里的快，到底是哪种快？

很多人把快默认理解成低延迟：一条消息发出去，下一毫秒就要被消费。Kafka 当然也在意延迟，但它最出名的能力不是“单条消息永远最低延迟”，而是持续搬运大量 records 的能力。

也就是 high throughput。

这两个东西不一样。

低延迟像外卖骑手送一单，追的是这一单多久到。高吞吐像港口卸货，追的是一小时能吞掉多少集装箱。你不能拿港口的设计去要求它像骑手一样灵活，也不能拿骑手的速度去推导一个港口的吞吐。

Kafka 更像后者。

它关心的是：数据能不能稳定地、大块地、连续地从 producer 进来，写进 log，再被 consumer 拉走。只要这条路径足够顺，单条消息上的一点点额外开销，被摊到一大批数据里，就不再那么显眼。

所以这篇文章不想把 Kafka 写成“低延迟神器”。它真正值得学的，是高吞吐系统怎么避开慢路径。

很多人第一次理解 Kafka 时，会卡在一个矛盾上：

消息不是落磁盘吗？磁盘不是慢吗？那 Kafka 为什么还快？

这个问题的坑在于，“磁盘慢”只说对了一半。

磁盘确实怕慢，但它怕的不是“被使用”，而是被随机、小块、来回折腾地使用。

Kafka 官方设计文档里有一组经典数字：在 6 块 7200rpm SATA 磁盘的配置下，线性写大约可以到 600MB/s，而随机写大约只有 100kB/s，差距超过 6000 倍。