大家好，我是yes。

我们都知道 RocketMQ 和 Kafka 消息都是存在磁盘中的，那为什么消息存磁盘读写还可以这么快？有没有做了什么优化？都是存磁盘它们两者的实现之间有什么区别么？各自有什么优缺点?

今天我们就来一探究竟。

存储介质-磁盘

一般而言消息中间件的消息都存储在本地文件中，因为从效率来看直接放本地文件是最快的，并且稳定性最高。毕竟要是放类似数据库等第三方存储中的话，就多一个依赖少一份安全，并且还有网络的开销。

那对于将消息存入磁盘文件来说一个流程的瓶颈就是磁盘的写入和读取。我们知道磁盘相对而言读写速度较慢，那通过磁盘作为存储介质如何实现高吞吐呢？

顺序读写

答案就是顺序读写。

首先了解一下页缓存，页缓存是操作系统用来作为磁盘的一种缓存，减少磁盘的I/O操作。

在写入磁盘的时候其实是写入页缓存中，使得对磁盘的写入变成对内存的写入。写入的页变成脏页，然后操作系统会在合适的时候将脏页写入磁盘中。

在读取的时候如果页缓存命中则直接返回，如果页缓存 miss 则产生缺页中断，从磁盘加载数据至页缓存中，然后返回数据。

并且在读的时候会预读，根据局部性原理当读取的时候会把相邻的磁盘块读入页缓存中。在写入的时候会后写，写入的也是页缓存，这样存着可以将一些小的写入操作合并成大的写入，然后再刷盘。

而且根据磁盘的构造，顺序 I/O 的时候，磁头几乎不用换道，或者换道的时间很短。

根据网上的一些测试结果，顺序写盘的速度比随机写内存还要快。

当然这样的写入存在数据丢失的风险，例如机器突然断电，那些还未刷盘的脏页就丢失了。不过可以调用 fsync 强制刷盘，但是这样对于性能的损耗较大。

因此一般建议通过多副本机制来保证消息的可靠，而不是同步刷盘。

可以看到顺序 I/O 适应磁盘的构造，并且还有预读和后写。 RocketMQ 和 Kafka 都是顺序写入和近似顺序读取。它们都采用文件追加的方式来写入消息，只能在日志文件尾部写入新的消息，老的消息无法更改。

mmap-文件内存映射

从上面可知访问磁盘文件会将数据加载到页缓存中，但是页缓存属于内核空间，用户空间访问不了，因此数据还需要拷贝到用户空间缓冲区。

可以看到数据需要从页缓存再经过一次拷贝程序才能访问的到，因此还可以通过mmap来做一波优化，利用内存映射文件来避免拷贝。

简单的说文件映射就是将程序虚拟页面直接映射到页缓存上，这样就无需有内核态再往用户态的拷贝，而且也避免了重复数据的产生。并且也不必再通过调用read或write方法对文件进行读写，可以通过映射地址加偏移量的方式直接操作。

sendfile-零拷贝

既然消息是存在磁盘中的，那消费者来拉消息的时候就得从磁盘拿。我们先来看看一般发送文件的流程是如何的。

简单说下DMA是什么，全称 Direct Memory Access ，它可以独立地直接读写系统内存，不需要 CPU 介入，像显卡、网卡之类都会用DMA。

可以看到数据其实是冗余的，那我们来看看mmap之后的发送文件流程是怎样的。

可以看到上下文切换的次数没有变化，但是数据少拷贝一份，这和我们上文提到的mmap能达到的效果是一样的。

但是数据还是冗余了一份，这不是可以直接把数据从页缓存拷贝到网卡不就好了嘛？sendfile就有这个功效。我们先来看看Linux2.1版本中的sendfile。

因为就一个系统调用就满足了发送的需求，相比 read + write 或者 mmap + write 上下文切换肯定是少了的，但是好像数据还是有冗余啊。是的，因此 Linux2.4 版本的 sendfile  + 带 「分散-收集（Scatter-gather）」的DMA。实现了真正的无冗余。

这就是我们常说的零拷贝，在 Java 中FileChannal.transferTo()底层用的就是sendfile。

接下来我们看看以上说的几点在 RocketMQ 和 Kafka中是如何应用的。