# Kafka为什么快：放弃的艺术——ByteByteGo神课深读 ## 导语：一条动画神课，拆穿“快”的错觉 工程圈有一条流传已久的测试题：“磁盘比内存慢得多，那为什么一个主要靠磁盘转的系统，能做到每秒吞吐上百万条消息？”大部分人在第一句就会卡住。而 ByteByteGo 频道（系统设计领域头部频道，创办人 Alex Xu，《System Design Interview》作者）的一期动画短课，把这道题拆得明明白白——这就是本期要深读的《Why is Kafka fast?》（Kafka 为什么快）。 这条视频讲的是 Apache Kafka——一个 2011 年从 LinkedIn 开源出来的消息系统，如今是几乎所有大型互联网公司的数据主动脉：订单、埋点、日志、风控事件，进出都要过一遍它。视频用不到二十分钟的动画，回答了一个反直觉的问题：**它凭什么这么快？** 答案不是黑科技，而是一组“反常识的放弃”：放弃随机访问、放弃用户态搬运、放弃逐条处理、放弃自建缓存。看完你会发现，所谓性能设计，很多时候不是“多做”，而是“少做”。 本文按视频的叙事顺序逐层拆解，再补上它没讲透的理论源头与边界条件——让你没看过视频也能懂，看过视频能多懂一层。 ## 视频背景卡片 | 项目 | 内容 | |------|------| | 视频标题 | Why is Kafka so Fast?（Kafka 为什么这么快？） | | 频道 | ByteByteGo（Alex Xu 主理的系统设计频道） | | 形式 | 动画讲解，约10分钟级别 | | 播放量 | 系统设计类长青爆款，长期被推荐（据频道公开页面量级，撰稿环境未能实时精确核对） | | 核心主题 | Kafka 高吞吐背后的5个设计决策及其通用原理 | > 说明：本篇为系列第2轮（编程与开发方向）。撰写环境的抓取通道受限，播放量等动态数据以频道公开页面的常见量级标注，未做实时精确核对；文中涉及的技术机制（sendfile、页缓存、Kafka 架构）均以 Linux 手册页、Apache Kafka 官方文档及原始论文为准。 ## 核心内容拆解 ### 1. 问题设定：Kafka 是什么，为什么人人都绕不开它 （视频内容）视频开篇先立好舞台：Kafka 本质上是一个**分布式的、只追加的日志（append-only log）**。生产者把消息写进某个主题（topic）的末尾，消费者按偏移量（offset）顺序读走，互不相见、互不等待。它存在的意义是把系统之间“点对点、同步等”的调用，改造成“写进公共管道、各自消费”的异步解耦——下游宕机不拖垮上游，流量洪峰先攒着再消化。 （延伸分析）很多人把 Kafka 当“消息队列”，但视频里那个动画其实在暗示更准确的心智模型：**它是一个提交日志（commit log），队列只是副产品**。这个区别决定了后面所有设计的走向——队列的天然语义是“取出即删除、随机消费”，而日志的语义是“只追加、可重放、按位置读”。Kafka 的快，一半来自它选择了后者：**日志模型天然排斥随机访问，而随机访问恰恰是存储系统一切噩梦的根源**。理解了这一点，后面五个“技巧”就不再是五个孤立的知识点，而是同一个决定在不同层面的展开。 ### 2. 第一个支柱：顺序 I/O——把磁盘用出内存的感觉 （视频内容）直觉告诉我们磁盘慢，但这个直觉默认的是**随机访问**：机械硬盘每次读写要等磁头寻道、盘片旋转，毫秒级的延迟在每秒上万的随机请求面前就是灾难。而 Kafka 的日志只追加、只顺序读写——磁头一旦定位就沿着磁道连续扫过去，吞吐瞬间上台阶。视频用了一个流传很广的对比：机械盘的**顺序**读写性能，可以逼近甚至超过它自己**随机**读写的成百上千倍，比很多人想象的“磁盘速度”高一两个数量级。 （延伸分析）这是全片最值得刻进脑子的一条：**谈论“磁盘慢不慢”之前，必须先回答“怎么访问”**。顺序化把慢介质用出了快的感觉，这个思想远不止 Kafka 一家在用：数据库的 WAL（预写日志）为什么先记日志再改数据？因为追加日志是顺序写。LSM-Tree 存储引擎（RocksDB 一族）为什么把随机更新先攒成内存表再批量刷盘？为了把随机变顺序。甚至 SSD 的固件（FTL）也在偷偷做同样的整理。**“日志是数据结构的灵魂”**——这句话是 Jay Kreps（Kafka 创造者之一）后来那篇著名长文《The Log》的核心论点，而 Kafka 就是这句话的产品化。 ### 3. 第二个支柱：零拷贝——数据在你看不见的地方被搬了四次 （视频内容）视频接着把镜头对准一个大多数程序员从没检查过的地方：数据从磁盘走到网卡，到底要搬动几次？不用任何优化时，答案是**四次拷贝、若干次内核/用户态上下文切换**：磁盘→内核页缓存→用户空间缓冲区→套接字缓冲区→网卡。每一次搬运都要 CPU 亲手把字节从一块内存复制到另一块，外加模式切换的开销。而对 Kafka 来说，从磁盘读消息发给消费者是最高频的动作，这条通路上却存在一个尴尬的事实——**数据只是路过用户空间，根本没人需要在用户空间处理它**。 于是 Kafka 把发送动作交给 Linux 的 `sendfile()` 系统调用：数据直接从页缓存送进网卡，跳过用户态的两次拷贝和两次模式切换。CPU 不再搬运字节，只负责“指路”；如果网卡支持 gather（散射-聚合）DMA，连网卡侧都只需拿到内存描述符而非数据本体。视频用动画把这条通路画得非常直观：原来的四段旅程，被裁成两段。 （延伸分析）这里要补一个视频没点破的关键细节：**零拷贝主要发生在“消费者拉取”这条读路径上**——写入路径靠的是另一招（顺序追加落盘），生产消息并不走 sendfile。读多写少的拉取场景恰好是消息系统最吃性能的地方，所以这一刀砍在了刀刃上。`sendfile` 并不是什么新玩具，它是 2000 年前后就进入 Linux 的老接口，最早为了加速 Web 服务器发静态文件而生——Kafka 的功劳不是发明它，而是**在自己的核心通路上把它用尽**。 ### 4. 第三、四个支柱：批量与压缩、分区并行 （视频内容）第三招是**批量（batching）**：生产者不逐条发送，而是把一个小时间窗内的消息攒成一批发出去；broker 端把同一批消息连续写进日志；消费者拉取时也是一次拖走一整段。网络传输和磁盘写入都有高昂的“固定成本”（协议握手、系统调用、I/O 提交），逐条处理等于为每条几百字节的消息支付整趟运费；攒批发货则把这笔钱摊到几万条消息头上。配套的一手是**压缩**：整批一起压缩远比逐条压缩划算，因为相邻消息往往高度相似，压缩率极高。 第四招是**分区（partition）**：一个主题在物理上被切成多个分区，分布在不同机器上，各自独立追加。单机的顺序 I/O 再快也有上限，想要更多吞吐，加分区、加机器，吞吐线性往上走。视频强调：这让 Kafka 的性能曲线不是“优化出更快的单点”，而是“可横向复制的标准单元”。 （延伸分析）批量这招值得单独咀嚼：**它本质上是在用延迟换吞吐**——攒批必然引入几毫秒到几十毫秒的等待，这正是 Kafka 被设计给“日志流”而非“逐条事务”用的原因之一。工程里很多性能手段都带着这层交换：视频里的每一招都不是免费的，认清代价才算真看懂。而分区并行则是把前两招乘上一个 N：顺序 I/O 与批量是“把单点做对”，分区是“把做对的东西复制到水平方向”——前者是必要条件，后者是规模化的杠杆。 ### 5. 第五个支柱：页缓存——把缓存交给操作系统，自己什么都不做 （视频内容）最后一招最反直觉：Kafka **不自己建内存缓存**。大多数系统会在进程里维护一块精心管理的缓存区，Kafka 却直接依赖操作系统的页缓存（page cache）：读写都从 OS 托管的缓存走，进程自己只管顺序地写文件、顺序地读文件。好处有三：缓存命中时不碰磁盘；JVM 不用为巨大的缓存堆做垃圾回收（避免了 GC 抖动）；哪怕 broker 进程重启，**页缓存还在操作系统手里，热数据依然热**——进程死了缓存不陪葬。 （延伸分析）这一条其实是“克制”的教科书案例：自己造缓存，意味着缓存失效、预取、并发、GC 压力一堆问题自己扛；而页缓存是内核团队优化了几十年的成熟实现，免费、稳健、进程无关。Kafka 的设计文档里明确写过这个取舍——**相信文件系统和页缓存，而不是绕开它们**。这与它在零拷贝上的思路一脉相承：不重新发明内核已经做好的事，把自己的代码从数据通路上挪走。整个视频看下来，“快”的五个支柱没有一个需要天才发现，需要的只是始终如一地顺着日志模型把“少做”贯彻到底。 ## 知识与理论溯源 视频里的每个点都有扎实的出处，值得对照深挖： - **Kafka 的出生**：2011 年，LinkedIn 的 Jay Kreps、Neha Narkhede、Jun Rao 发表论文《Kafka: a Distributed Messaging System for Log Processing and Messaging》，明确把“顺序磁盘访问 + 零拷贝”列为设计基石。Narkhede 与 Kreps 后来创办了 Confluent，把 Kafka 推成流处理事实标准。 - **日志抽象**：Kreps 2013 年的长文《The Log: What every software engineer should know about real-time data's unifying abstraction》把 Kafka 背后的哲学讲透——日志是分布式系统、数据库、流处理的公共底层。视频里所有技巧，都是这篇论文思想在性能层面的投影。 - **sendfile 与零拷贝**：Linux 手册页（man7.org）对 `sendfile(2)` 的说明直接使用了"zero-copy"一词；它的引入是为了让 Web 服务器发送静态文件时绕开用户态搬运。Kafka 消费路径只是这个老接口的一次成功移植。 - **顺序 vs 随机**：“机械盘顺序访问比随机访问快一到三个数量级”是存储领域的常识性结论，数据库教材与分布式系统课程（如 MIT 6.824 的存储讲次）都会先讲这一页。 ## 批判性审查：哪些是真招，哪些是简化 **证据充分的部分**：顺序 I/O、页缓存、批量压缩、分区扩展，全部是 Kafka 官方文档与原始论文白纸黑字写明的设计决策，机制层面无争议。`sendfile` 零拷贝也是消费者路径的确定事实。 **需要校准的部分**，有四处： 1. **“零拷贝”不是全程零拷贝。** 一旦启用 TLS 加密（今天的企业标配），经典 sendfile 路径就会中断——加密必须有人来做，数据又得绕回可执行加密的位置。近年内核与 OpenSSL 推动的 kTLS 正是为了把加密放进内核、把零拷贝找回来。视频没提这层，实操中这恰恰是“为什么我们上了 Kafka 却没看到想象中的性能”的常见原因之一。 2. **“顺序写快过内存随机访问”一类表述要打折听。** 顺序盘吞吐高是真的，但内存的延迟量级仍远低于任何磁盘——传播中被夸张成“磁盘顺序读比内存快”的版本并不成立。两个介质的差距是真实的，但没有奇迹。 3. **分区不是越多越好。** 视频讲“加分区加吞吐”是简化版。分区过多的集群会付出文件句柄、页缓存碎片化、 controller 管理开销等代价，社区早有共识：每个分区的消息写入都会变成独立的顺序流，流太碎反而把顺序优势切碎。这是新手上 Kafka 最常踩的坑。 4. **“快”的前提是工作负载匹配。** Kafka 不做随机点查、不做复杂事务、不支持按内容索引——它快，是因为它只干日志模型擅长的事。拿它当数据库用，五个支柱会一个一个塌掉。快是放弃换来的，这是全片最该带走却最容易被“6个技巧”清单掩埋的一句话。 ## 认知提升与实用启示 **第一，性能审查先查“搬运次数”，再查算法。** 多数性能问题不在算法复杂度，而在数据通路上多出来的那两次拷贝、那几次上下文切换、那趟多余的序列化。下次你的服务在压测下掉链子，先画一张“数据从哪来、到哪去、中途被复制几次”的图——Kafka 给的启示是：**把没人需要的搬运环节直接从通路上拆掉，比任何微优化都值钱。** **第二，把“顺序化”当成通用设计本能。** 面对随机访问的慢，先问一句：能不能把访问模式改成顺序？写日志、攒批次、批量刷盘、追加存储——从数据库 WAL 到 SSD 固件，这个思想在每一层存储栈里反复出现。识别出“这个系统其实是日志”的那一刻，优化方案往往自己浮出来。 **第三，为每个“快”索取它的放弃清单。** 下次有人向你推销一个快得惊人的系统，别先问“它为什么快”，先问“**它不做哪些事**”。Kafka 的答案清单（不做随机读、不做事务、不做逐条低延迟）正是它快的全部预算。一张“不支持清单”比一页性能数字更能告诉你这个系统适不适合你。 ## 知识结构图 ```mermaid flowchart TD Q["Kafka为什么快"] --> A["支柱一：顺序I/O"] Q --> B["支柱二：零拷贝"] Q --> C["支柱三：批量+压缩"] Q --> D["支柱四：分区并行"] Q --> E["支柱五：页缓存"] A --> A1["顺序与随机
差1~3个数量级"] B --> B1["sendfile
砍掉用户态搬运"] C --> C1["摊薄I/O与网络固定成本"] D --> D1["加机器即加吞吐"] E --> E1["进程重启缓存不陪葬"] A1 --> Z["共同前提：只追加
只整块、不随机"] B1 --> Z C1 --> Z D1 --> Z E1 --> Z Z --> W["快，是放弃换来的"] ``` ## 延伸阅读 1. **《The Log：What every software engineer should know about real-time data's unifying abstraction》** — Jay Kreps 撰写的行业长文（LinkedIn Engineering 博客及 ACM Queue 均有收录），Kafka 视频背后全部哲学的原始出处，讲“日志”如何统一数据库、分布式与流处理。 2. **Apache Kafka 官方文档《Introduction》** — kafka.apache.org/intro，官方对日志模型、生产者消费者语义的最权威表述，配合视频食用最佳。 ## 参考来源 1. [ByteByteGo — Why is Kafka fast?（YouTube 检索入口）](https://www.youtube.com/results?search_query=ByteByteGo+why+is+Kafka+fast) — 本期深读的视频，ByteByteGo 系统设计动画系列 2. [Apache Kafka 官方文档](https://kafka.apache.org/intro) — Kafka 设计理念与日志模型的官方一手表述 3. [Linux man-pages: sendfile(2)](https://man7.org/linux/man-pages/man2/sendfile.2.html) — 零拷贝机制的系统调用手册页 4. [ByteByteGo 官网](https://bytebytego.com/) — Alex Xu 的系统设计平台，视频所在系列的内容主页 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。