如何在RocketMQ和Kafka中实现顺序IO

首先需要明确：两款消息队列宣称的顺序IO是文件系统层面的逻辑顺序写入，并不要求物理磁盘层面存在连续的1G扇区空间，操作系统的文件系统块管理机制会屏蔽物理磁盘的空间分布差异，即使没有连续1G物理空间也可以实现顺序IO的性能收益，具体实现逻辑如下：

Kafka实现逻辑 #

• Kafka默认每个日志分段（segment）的逻辑大小为1G，该大小是文件的逻辑长度，不需要对应物理磁盘的连续空间。Kafka调用pwrite接口按文件偏移量递增的规则追加写入，文件系统会自动将逻辑连续的写入请求映射到离散的物理磁盘块，只要写入时保持偏移量递增的顺序，磁头寻道次数远低于随机写，即可获得顺序IO的性能收益。
• 写入时先将数据写入操作系统页缓存，由操作系统后台异步批量刷盘，单次刷盘会合并多个离散物理块的写入请求，进一步降低IO开销。
• 写满的1G分段文件几乎不会被修改，后续读取时可利用页缓存的预读机制，即使物理块不连续，顺序读取性能也接近连续物理块的读取效率。

RocketMQ实现逻辑 #

• RocketMQ的CommitLog默认每个文件逻辑大小为1G，同样不依赖物理磁盘连续空间。所有消息写入统一在当前活跃CommitLog文件的末尾追加，逻辑上保持偏移量递增，文件系统负责逻辑偏移到物理块的映射，上层业务无需感知物理空间分布。
• 采用MappedByteBuffer内存映射文件机制，将1G逻辑文件直接映射到进程虚拟地址空间，写入时直接操作虚拟内存，由操作系统负责同步到磁盘，即使物理块离散，写入逻辑依然保持顺序。
• 若当前磁盘分区剩余空间不足以创建新的1G CommitLog文件，RocketMQ会自动切换到其他可用磁盘分区创建新文件，写入流程依然保持追加模式，不会退化为随机写。

核心结论：两款产品的顺序IO性能收益本质来源于「同一逻辑文件内的偏移量递增写入模式」，和物理磁盘是否存在连续1G空间没有直接关联。

内容的提问来源于stack exchange，提问作者XHMao