先了解一下CommitLog消息顺序写入机制

当生产者发送一个消息到Broker上的时候，Broker接受到一条消息之后，会把这个消息直接写到磁盘上的一个日志文件，这个文件叫做CommitLog，直接顺序写入这个CommitLog是很多磁盘文件，每个文件限定最多1GB，Broker收到消息之后直接追加写入这个文件的末尾，如果一个CommitLog写满1GB，就会创建一个新的CommitLog日志。如下图所示：

image.png

MssageQueue在数据存储中是体现在哪里

其实在Broker中， 每个Topic下的每个MessageQueue都会有一系列的ConsumeQueue文件，这个是什么意思呢，就是说Broker的磁盘上，会有下面格式的一系列的文件：/home/store/cousumequeue/{topicid}/{queueid}/{fileName}，这个文件格式各个目录代表的意思就是：对每个Topic在这台Broker上面不都是有一些MessageQueue么，所以{topicid}就是代表的某个topic，{queueid}指的就是某个MessageQueue，然后存储在这个Broker上的Topic下的一个MessageQueue会有多个ConsumeQueue文件，这个ConsumeQueue文件中存储的就是一条消息在CommitLog中存放的offset偏移量。是不是有点晕，别急对这句话的解释如下看图：

image.png

假设一个消息发送到这个Broker上那么这个Broker上面有两个MessageQueue也就是MessageQueue0和MessageQueue1，那么上图画的ConsumeQueue0和ConsumeQueue1分别就是和MessageQueue0和MessageQueue1对应着。假设这个Topic叫做TopicOrderPaySuccess，那么在磁盘上应该有如下两个路径文件：

/home/store/cousumequeue/TopicOrderPaySuccess/MessageQueue0/ConsumeQueue0
/home/store/cousumequeue/TopicOrderPaySuccess/MessageQueue1/ConsumeQueue1

然后呢，当Broker接受到一条消息写入CommitLog之后，其实同时也会将这条数据的在CommitLog中存储的物理位置，也就是一个文件偏移量，就是offset写入这条消息所处的MessageQueue对应的ConsumeQueue文件中。
假设一个消息发送到MessageQueue0上面那么Broker就会把这条消息在CommitLog中的偏移量offset写入到这个MessageQueue0所对应的ConsumeQueue0上。ConsumeQueue中的存储的这个物理位置（偏移量offset）其实就是对CommitLog文件的一个消息引用。其实ConsumeQueue文件中不只是存了消息引用，还包含了消息的长度，以及tag，还有hashcode,一条数据是20个字节，每个ConsumeQueue文件保存30万条数据，大概每个文件是5.72MB。

image.png

如何让消息写入CommitLog的性能接近写内存性能

Broker是基于OS操作系统的PageCache和顺序写机制，来提升CommitLog的文件写入性能。顺序写的意思就是Broker每次都是将消息写入CommitLog的文件中时，就是在文件的末尾加一条数据就可以了。顺序写的性能要比随机写的性能高很多倍。还有就是所说的利用os操作系统的PageCache，就是数据写入CommitLog的时候，其实不是直接写入底层的物理磁盘文件的，而是先进入OS的PageCache内存缓存中然后后续有os的后台线程选一个时间，异步化的将OS PagCache内存缓存的数据刷入到物理磁盘中。所以利用 顺序写+OS PageCache写入+异步刷盘策略，可以将写CommitLog文件的性能和写内存的性能差不多。

image.png

异步刷入磁盘可能会造成数据的丢失，但是这样的话性能比较高，RocketMQ还支持一种模式就是同步刷盘，就是必须真正的写入到物理磁盘后才会返回ack给生产者，但是这样的话写入性能就会大打折扣。