RocketMQ 和 Kafka 的应用

RocketMQ

采用Topic混合追加方式，即一个 CommitLog 文件中会包含分给此 Broker 的所有消息，不论消息属于哪个 Topic 的哪个 Queue 。

所以所有的消息过来都是顺序追加写入到 CommitLog 中，并且建立消息对应的 CosumerQueue ，然后消费者是通过 CosumerQueue 得到消息的真实物理地址再去 CommitLog 获取消息的。可以将 CosumerQueue 理解为消息的索引。

在 RocketMQ 中不论是 CommitLog 还是 CosumerQueue 都采用了 mmap。

可以看到 RocketMQ 默认把消息拷贝到堆内 Buffer 中，再塞到响应体里面发送。但是可以通过参数配置不经过堆，不过也并没有用到真正的零拷贝，而是通过mapedBuffer 发送到 SocketBuffer 。

所以 RocketMQ 用了顺序写盘、mmap。并没有用到 sendfile ，还有一步页缓存到 SocketBuffer 的拷贝。

然后拉消息的时候严格的说对于 CommitLog 来说读取是随机的，因为 CommitLog 的消息是混合的存储的，**但是从整体上看，消息还是从 CommitLog 顺序读的，都是从旧数据到新数据有序的读取。**并且一般而言消息存进去马上就会被消费，因此消息这时候应该还在页缓存中，所以不需要读盘。

而且我们在上面提到，页缓存会定时刷盘，这刷盘不可控，并且内存是有限的，会有swap等情况，而且**mmap其实只是做了映射，当真正读取页面的时候产生缺页中断，才会将数据真正加载到内存中，**这对于消息队列来说可能会产生监控上的毛刺。

因此 RocketMQ 做了一些优化，有：文件预分配和文件预热。

文件预分配

CommitLog 的大小默认是1G，当超过大小限制的时候需要准备新的文件，而 RocketMQ 就起了一个后台线程 AllocateMappedFileService，不断的处理 AllocateRequest，AllocateRequest其实就是预分配的请求，会提前准备好下一个文件的分配，防止在消息写入的过程中分配文件，产生抖动。

文件预热

有一个warmMappedFile方法，它会把当前映射的文件，每一页遍历多去，写入一个0字节，然后再调用mlock 和 madvise(MADV_WILLNEED)。

我们再来看下this.mlock，内部其实就是调用了mlock 和 madvise(MADV_WILLNEED)。

mlock：可以将进程使用的部分或者全部的地址空间锁定在物理内存中，防止其被交换到swap空间。

madvise：给操作系统建议，说这文件在不久的将来要访问的，因此，提前读几页可能是个好主意。

RocketMQ 小结

顺序写盘，整体来看是顺序读盘，并且使用了 mmap，不是真正的零拷贝。又因为页缓存的不确定性和 mmap 惰性加载(访问时缺页中断才会真正加载数据)，用了文件预先分配和文件预热即每页写入一个0字节，然后再调用mlock 和 madvise(MADV_WILLNEED)。

Kafka

Kafka 的日志存储和 RocketMQ 不一样，它是一个分区一个文件。

Kafka 的消息写入对于单分区来说也是顺序写，如果分区不多的话从整体上看也算顺序写，它的日志文件并没有用到 mmap，而索引文件用了 mmap。但发消息 Kafka 用到了零拷贝。

对于消息的写入来说 mmap 其实没什么用，因为消息是从网络中来。而对于发消息来说 sendfile 对比 mmap+write 我觉得效率更高，因为少了一次页缓存到 SocketBuffer 中的拷贝。

来看下Kafka发消息的源码，最终调用的是 FileChannel.transferTo，底层就是 sendfile。

从 Kafka 源码中我没看到有类似于 RocketMQ的 mlock 等操作，我觉得原因是首先日志也没用到 mmap，然后 swap 其实可以通过 Linux 系统参数 vm.swappiness 来调节，这里建议设置为1，而不是0。

假设内存真的不足，设置为 0 的话，在内存耗尽的情况下，又不能 swap，则会突然中止某些进程。设置个 1，起码还能拖一下，如果有良好的监控手段，还能给个机会发现一下，不至于突然中止。

RocketMQ & Kafka 对比

首先都是顺序写入，不过 RocketMQ 是把消息都存一个文件中，而 Kafka 是一个分区一个文件。

每个分区一个文件在迁移或者数据复制层面上来说更加得灵活。

但是分区多了的话，写入需要频繁的在多个文件之间来回切换，对于每个文件来说是顺序写入的，但是从全局看其实算随机写入，并且读取的时候也是一样，算随机读。而就一个文件的 RocketMQ 就没这个问题。

从发送消息来说 RocketMQ 用到了 mmap + write 的方式，并且通过预热来减少大文件 mmap 因为缺页中断产生的性能问题。而 Kafka 则用了 sendfile，相对而言我觉得 kafka 发送的效率更高，因为少了一次页缓存到 SocketBuffer 中的拷贝。

并且 swap 问题也可以通过系统参数来设置。

最后

这篇文章中间写 RocketMQ 卡壳了，源码还是不太熟，有点绕。 多亏丁威大佬的点拨。不然我就陷入了死胡同出不来了。

最后再推荐下丁威大佬和周继锋大佬的《RocketMQ技术内幕：RocketMQ架构设计与实现原理》。对 RocketMQ 有兴趣的同学可以看看。

文章如果哪里有纰漏请抓紧联系我，感谢！