摘要：很多人以为Kafka写消息是直接写磁盘，其实FileChannel.write只写OS Page Cache。本文从LogSegment.append六步流程切入，拆解MemoryRecords构造、FileChannel写入路径、Page Cache回写机制、三层持久化保障，讲透Kafka为什么用Buffered IO而非Direct IO，以及一条消息从Producer到磁盘的完整旅程。

从一个常见误解切入

面试时常被问："Kafka为什么写那么快？“很多人答"顺序写磁盘”。这个答案只对了一半。

顺序写确实是关键，但Kafka的write()系统调用根本不直接写磁盘。FileChannel.write(ByteBuffer)把数据从用户态拷贝到内核态的Page Cache后就立即返回，真正的磁盘写入由操作系统的pdflush线程异步完成。换句话说，Kafka的高吞吐不是"写磁盘快"，而是"写内存快"——磁盘只是最终归宿，不是写入路径上的瓶颈。

这篇沿着上一篇稀疏索引的线索，把Log.append流程中"写.log数据文件"这一步彻底拆开：从LogSegment.append的六步链路，到MemoryRecords的二进制构造，到FileChannel.write进入内核后的Page Cache机制，再到三层持久化保障。读完你会理解Kafka为什么选择Buffered IO而非Direct IO，以及acks=all到底在等什么。

01 写消息的完整路径：用户态→Page Cache→磁盘

一条消息从Producer发出到最终落盘，经过三层空间：

用户态（Kafka进程内）：Producer端序列化、分区路由、RecordAccumulator攒批；Sender线程按Broker分组发送；Broker端RequestHandler线程从requestQueue取出请求，KafkaApis.handleProduceRequest → ReplicaManager.appendRecords → Partition.append → Log.append → LogSegment.append。整个调用链在JVM内完成，不涉及磁盘IO。

内核态（OS Page Cache）：LogSegment.append最终调用FileRecords.append → channel.write(buffer)。write()系统调用把DirectByteBuffer的数据从用户态拷贝到内核态的Page Cache（4KB为单位的内存页），标记为dirty后立即返回。此时数据在内存中，不在磁盘上。

磁盘（异步回写）：内核的pdflush/kworker线程定期扫描dirty页，满足条件（dirty_expire_centisecs默认30秒，或dirty_ratio达20%）时批量回写到磁盘。ext4文件系统的journal先写元数据日志再写数据，崩溃后可恢复。

这个设计的核心判断是：Page Cache是免费的内存数据库。Kafka不自己实现缓存层，直接复用OS已经做好的页缓存，写时攒批、读时命中、淘汰由OS LRU自动管理。

02 LogSegment.append六步流程

LogSegment.append是写数据文件的核心方法，六步完成一次批次写入：

第一步：锁与校验。获取partitionLock（ReentrantLock），检查当前副本是否为leader、消息格式版本是否兼容、分区是否只读。锁粒度是partition级别，同一partition的写入串行化，不同partition并行。

第二步：分配offset。baseOffset = logEndOffset（LEO），每批消息分配连续的offset区间。如果一批有N条消息，占用[baseOffset, baseOffset+N-1]。分配后立即更新LEO，后续写入基于新LEO。

第三步：构造MemoryRecords。MemoryRecordsBuilder按RecordBatch格式构造二进制数据：先写Batch Header（61字节以上），再逐条写Record（变长编码）。如果配置了压缩，多条Record打包压缩后写入Batch的value字段。

第四步：FileChannel.write。FileRecords.append调用channel.write(buffer)，把MemoryRecords的ByteBuffer写入Page Cache。写入前记录channel.position()作为physicalPosition（消息在.log文件中的起始字节位置），这个值后续用于稀疏索引和LEO元数据。

第五步：更新offset元数据。构造LogOffsetMetadata，包含三个字段：messageOffset（绝对offset）、segmentBaseOffset（所在段的baseOffset）、relativePositionInSegment（段内物理位置）。这个三元组是查找消息的关键——消费者fetch时按offset定位段，再按physicalPosition seek。

第六步：更新稀疏索引。bytesSinceLastIndexEntry累加本批消息字节数，达到index.interval.bytes（默认4096）时调用offsetIndex.append和timeIndex.append，通过mmap写入.index和.timeindex文件（上一篇详细讲过）。

03 MemoryRecords的二进制构造

MemoryRecords不是简单的字节数组，它有严格的二进制格式。理解这个格式对理解写入性能和磁盘占用至关重要。

RecordBatch Header（最小61字节）：

firstOffset(8B) + length(4B) + partitionLeaderEpoch(4B) + magic(1B) + crc(4B) + attributes(2B) + lastOffsetDelta(4B) + firstTimestamp(8B) + maxTimestamp(8B) + producerId(8B) + producerEpoch(2B) + baseSequence(4B) + recordCount(4B)

magic字段标识消息格式版本（当前v2=2），attributes低3位编码压缩类型（0=none,1=gzip,2=snappy,3=lz4,4=zstd），第3位标识时间戳类型（CreateTime/LogAppendTime）。

Record（变长编码）：

length(varint) + attributes(1B) + timestampDelta(varlong) + offsetDelta(varint) + keyLength(varint) + key + valueLength(varint) + value + headersCount(varint) + headers

变长编码（varint/varlong）是Kafka节省空间的关键：小数字用1-2字节，大数字才用更多字节。offsetDelta和timestampDelta都是相对Batch首条的增量，通常很小，1字节即可。

压缩时的特殊处理：配置压缩后，一个RecordBatch内的多条Record先序列化，再整体压缩（gzip/snappy/lz4/zstd），压缩结果作为唯一一条Record的value写入。Batch Header的recordCount记录原始消息数，解压后可恢复。这就是为什么压缩能显著降低磁盘占用和网络传输——重复的字段（如相同的key前缀、相似的value）在压缩算法中被高效编码。

04 为什么用Buffered IO而非Direct IO

Kafka写数据文件用FileChannel（Buffered IO），写索引用mmap，两种都经过Page Cache。为什么不用O_DIRECT绕过Page Cache直接写磁盘？

第一，写吞吐差一个数量级。Direct IO每次write都要等磁盘IO完成，机械盘随机写100 IOPS、SSD随机写1万IOPS，而Page Cache写是内存操作，百万级IOPS。消息队列的核心诉求是高吞吐写入，Buffered IO天然适配。

第二，失去零拷贝读取。Kafka消费者fetch数据时，如果数据在Page Cache中，用sendfile系统调用直接从Page Cache → 网卡，不经过用户态。如果用Direct IO，数据不在Page Cache，每次读都要从磁盘加载到用户态再发给消费者，多两次拷贝。Kafka的"零拷贝"完全依赖Page Cache命中。

第三，批量写效率。Page Cache把多次小write合并成一次大的顺序磁盘写（pdflush回写时按磁盘扇区排序），减少磁盘寻道。Direct IO每次写都是独立的磁盘操作，小批量写入效率极低。

第四，无需自行管理缓存。如果绕过Page Cache，Kafka需要自己实现一个内存缓存层（类似HBase的MemStore），管理写入、淘汰、持久化，复杂度大幅增加。复用OS Page Cache等于免费获得一个经过几十年优化的缓存系统。

当然Buffered IO有代价：掉电时Page Cache中未回写的数据丢失。Kafka的解法不是频繁fsync，而是多副本冗余——下一节详细讲。

05 三层持久化保障

Kafka的持久化不靠单机fsync，而是三层机制叠加：

第一层：OS异步回写（默认路径）。write()后数据在Page Cache中标记dirty，pdflush线程定期回写。关键参数：dirty_expire_centisecs（默认3000=30秒，dirty页超过30秒强制回写）、dirty_background_ratio（默认10%，脏页占内存10%时后台启动回写不阻塞write）、dirty_ratio（默认20%，达20%时write同步阻塞等待回写）。正常流量下30秒内数据落盘，异常流量（写入远超磁盘带宽）下dirty_ratio触发背压。

第二层：Kafka主动flush（可选，默认关闭）。两个配置：log.flush.interval.messages（每写N条force一次，默认Long.MAX_VALUE不触发）、log.flush.interval.ms（每N毫秒force一次，默认null不触发）。LogManager的ScheduledTask周期性检查各partition，满足条件调用log.flush() → segment.flush() → channel.force(true)，触发fsync系统调用。生产环境几乎不配置——fsync是同步阻塞，频繁调用会把吞吐从百万条/秒降到几千条/秒。

第三层：副本机制（真正的持久化保障）。Producer配置acks=all时，Leader写入Page Cache后不立即返回，等待ISR（In-Sync Replicas）中所有Follower拉取并写入各自的Page Cache后才确认。HW（High Watermark）是ISR中最小的LEO，只有HW之前的消息对消费者可见。Leader宕机时从ISR选新Leader，已复制到多数副本的消息不丢。配合min.insync.replicas≥2，即使一个副本宕机，写入仍被拒绝而非静默丢消息。

关键认知：acks=all不等同于数据落盘。它等的是所有ISR副本的Page Cache写入完成，不是fsync。真正的磁盘落盘仍由OS异步完成。但因为数据存在于多个Broker的Page Cache中，同时掉电的概率极低，且Kafka支持unclean.leader.election.enable=false防止落后副本当选Leader，持久性已经足够强。

06 真实源码解读

LogSegment.append的核心实现（基于Kafka 2.8源码，简化注释）：

defappend(largestOffset:Long,largestTimestamp:Long,shallowOffsetOfMaxTimestamp:Long,records:MemoryRecords):LogOffsetMetadata={// 写入前记录.log文件当前大小 = 本批消息的物理起始位置valphysicalPosition=log.sizeInBytes()if(records.sizeInBytes>0){// FileRecords.append → channel.write，写入Page Cachelog.append(largestOffset,largestTimestamp,shallowOffsetOfMaxTimestamp,records)// 累加自上次索引写入以来的字节数bytesSinceLastIndexEntry+=records.sizeInBytes// 达到间隔（默认4KB）才写一条稀疏索引if(bytesSinceLastIndexEntry>=indexIntervalBytes){valrelativeOffset=(largestOffset-baseOffset).toInt offsetIndex.append(relativeOffset,physicalPosition)timeIndex.append(largestTimestamp,relativeOffset)bytesSinceLastIndexEntry=0}}// 返回新的LEO元数据：绝对offset + 段baseOffset + 段内物理位置LogOffsetMetadata(firstOffset,baseOffset,physicalPosition)}

FileRecords.append的实现更短：

overridedefappend(records:MemoryRecords):Unit={// 写入前记录position，用于校验写入完整性valstartPos=channel.position()if(records.sizeInBytes>0){// channel.write可能部分写入，需循环直到写完varwritten=0while(written<records.sizeInBytes){written+=channel.write(records.buffer.duplicate())}}}

注意channel.write的返回值可能小于buffer.remaining()——非阻塞模式下内核缓冲区满时会部分写入，Kafka用while循环保证全部写入。实际生产中几乎不会触发部分写入，因为Page Cache通常有足够空间。

写入后Log.updateLogEndOffset更新LEO，ReplicaManager检查acks策略：如果acks=all，把请求加入delayedProduce等待ISR副本同步；如果acks=1，立即返回响应给Producer。

07 与mmap索引写入的对比

上一篇讲了稀疏索引用mmap写入，这篇讲数据文件用FileChannel+Page Cache写入。两种方式的选择不是随意的：

核心逻辑：数据文件批量大、顺序写，FileChannel一次系统调用写一批，摊销开销小；索引文件条目小、按位置随机写，mmap.putInt直接写内存地址，省去每次8字节都要系统调用的开销。两者都经过Page Cache，都靠OS异步回写，持久化策略一致。

写在最后

Kafka基于OS Cache写消息，本质是一个朴素的工程判断：内存比磁盘快三个数量级，能写内存就不写磁盘。FileChannel.write把数据丢进Page Cache就返回，pdflush异步回写，消费者读取时命中Page Cache走sendfile零拷贝——写入和读取都受益于同一份内存缓存。

持久化不靠单机fsync（那会毁掉吞吐），而靠多副本冗余：acks=all确保数据写入多个Broker的Page Cache，同时掉电概率极低，配合ISR机制和HW截断保证一致性。理解了这一层，再看Kafka的配置就有了判断依据：为什么默认不配置flush间隔、为什么生产环境推荐acks=all+min.insync.replicas=2、为什么Broker机器要留足够内存给Page Cache而不是全给JVM堆。