RocketMq的消息存储介质
RocketMQ采用文件存储机制，即是选择磁盘文件来存储消息。消息刷盘至所部署虚拟机/物理机的文件系统来做持久化（刷盘一般可以分为异步刷盘和同步刷盘两种模式）。
如何保证消息的存储和发送的性能
①消息存储-顺序写
RocketMQ的消息用顺序写,保证了消息存储的速度。磁盘如果使用得当，磁盘的速度完全可以匹配上网络 的数据传输速度。目前的高性能磁盘，顺序写速度可以达到600MB/s， 超过了一般网卡的传输速度。但是磁盘随机写的速度只有大概100KB/s，和顺序写的性能相差6000倍！因为有如此巨大的速度差别，好的消息队列系统会比普通的消息队列系统速度快多个数量级。RocketMQ的消息用顺序写,保证了消息存储的速度。
②消息发送-零拷贝
RocketMQ使用了mmap（内存映射技术）的方式，也就是所谓的“零拷贝”技术，提高消息存盘和网络发送的速度。
Linux操作系统分为【用户态】和【内核态】，文件操作、网络操作需要涉及这两种形态的切换，免不了进行数据复制。
一台服务器 把本机磁盘文件的内容发送到客户端，一般分为两个步骤：
1）read；读取本地文件内容；
2）write；将读取的内容通过网络发送出去。
这两个看似简单的操作，实际进行了4 次数据复制，分别是：
- 从磁盘复制数据到内核态内存；
- 从内核态内存复 制到用户态内存；
- 然后从用户态 内存复制到网络驱动的内核态内存；
- 最后是从网络驱动的内核态内存复 制到网卡中进行传输。
通过使用mmap的方式，可以省去向用户态的内存复制，提高速度。
消息存储结构
在上面的RocketMQ的消息存储整体架构图中可以看出，RocketMQ采用的是混合型的存储结构，即为Broker单个实例下所有的队列共用一个日志数据文件（即为CommitLog）来存储。RocketMQ的混合型存储结构(多个Topic的消息实体内容都存储于一个CommitLog中)针对Producer和Consumer分别采用了数据和索引部分相分离的存储结构。
RocketMQ主要的存储文件包括commitlog文件、consumequeue文件、indexfile文件。
CommitLog 文件：
消息存储文件，所有主题的消息随着到达 Broker 的顺序写入 CommitLog 文件，每个文件默认为1G（当文件超过1g容不下新数据的时候，就会新建一个commitLog文件），文件的命名也及其巧妙，使用该存储在消息文件中的第一个全局偏移量来命名文件，这样的设计主要是方便根据消息的物理偏移量，快速定位到消息所在的物理文件。RocketMQCommitLog 文件使用顺序写，极大提高了文件的写性能。
ConsumeQueue 文件：
消息消费队列文件，是 CommitLog 文件的基于 Topic 的索引文件，主要用于消费者根据 Topic消费消息，其组织方式为 /topic/queue，同一个队列中存在多个文件，ConsumeQueue 设计极具技巧性，其每个条目使用固定长度（8字节 CommitLog 物理偏移量、4字节消息长度、8字节 Tag HashCode），这里不是存储 tag 的原始字符串，而是存储 HashCode，目的就是确保每个条目的长度固定，可以使用访问类似数组下标的方式来快速定位条目，极大的提高了 ConsumeQueue文件的读取性能，试想一下，消息消费者根据 Topic、消息消费进度(ConsumeQueue 逻辑偏移量)，即第几个 ConsumeQueue 条目，这样根据消费进度去访问消息的方法为使用逻辑偏移量logicOffset* 20即可找到该条目的起始偏移量( ConsumeQueue 文件中的偏移量)，然后读取该偏移量后20个字节即得到了一个条目，无需遍历 ConsumeQueue 文件。
IndexFile 文件：
基于物理磁盘文件实现 Hash 索引。其文件由40字节的文件头、500W个 Hash 槽，每个 Hash 槽为4个字节，最后由2000万个 Index 条目，每个条目由20个字节构成，分别为4字节的索引key的 HashCode、8字节消息物理偏移量、4字节时间戳、4字节的前一个Index条目( Hash 冲突的链表结构)。
RMQ发送、消费逻辑
发送逻辑
发送时，Producer将不同topic的所有消息都会顺序写入Commit Log中，Broker端的后台服务线程—ReputMessageService不停地分发请求并异步构建ConsumeQueue（逻辑消费队列）和IndexFile（索引文件）数据，不停的轮询，将当前的consumeQueue中的offSet和commitLog中的offSet进行对比，将多出来的offSet进行解析，然后put到consumeQueue中的MapedFile中。
ConsumeQueue（逻辑消费队列）作为消费消息的索引，保存了指定Topic下的队列消息在CommitLog中的起始物理偏移量offset，消息大小size和消息Tag的HashCode值。而IndexFile（索引文件）则只是为了消息查询提供了一种通过key或时间区间来查询消息的方法（ps：这种通过IndexFile来查找消息的方法不影响发送与消费消息的主流程）。
消费逻辑
消费者在消费的时候先从consumequeue中根据偏移量定位到具体的commitlog物理文件，然后根据一定的规则（offset和文件大小取模）在commitlog中快速定位。
刷盘机制
消息先存到内存中，然后根据刷盘策略刷到磁盘上。
RocketMQ的消息是存储到磁盘上的，这样既能保证断电后恢复， 又可以让存储的消息量超出内存的限制。RocketMQ为了提高性能，会尽可能地保证磁盘的顺序写。消息在通过Producer写入RocketMQ的时 候，有两种写磁盘方式，分布式同步刷盘和异步刷盘。
1）同步刷盘
在返回写成功状态时，消息已经被写入磁盘。具体流程是，消息写入内存的PAGECACHE后，立刻通知刷盘线程刷盘， 然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，返回消息写成功的状态。同步刷盘对MQ消息可靠性来说是一种不错的保障，但是性能上会有较大影响，一般适用于金融业务应用领域。
2）异步刷盘
在返回写成功状态时，消息可能只是被写入了内存的PAGECACHE，写操作的返回快，吞吐量大；当内存里的消息量积累到一定程度时，统一触发写磁盘动作，快速写入。提高了MQ的性能和吞吐量。