了解消息存储部分首先需要关注的几个方法，load()--Load previously stored messages、start()--Launch this message store、putMessage--Store a（or batch） message into store.
以及一些关键词：
commitLog： 消息的物理存储相关
consumeQueue： 逻辑队列存储相关
IndexFile： 消息存储索引
刷盘： 将写入内存的消息持久化
主从同步(HAService)： Master中的数据同步到Slave中
load()方法： 用于重启时，加载数据
load()方法用于重启时，加载数据，初始化boker时，boker中的initialize方法中会调用messageStore.load()，包括：commitLog.load()、 loadConsumeQueue()、 indexService.load、 recover(lastExitOK)
正文：
（一）消息存储开启基础服务 -- 在后台运行，时刻准备为存储服务
boker启动时，会初始化DefaultMessageStore，调用DefaultMessageStore.start()服务。
I. 初始化DefaultMessageStore时开启的服务
预分配MapedFile对象服务(线程)：AllocateMapedFileService
分发消息索引服务（线程）： DispatchMessageService --（注：rockemq4.0版本中抛弃了该服务，对应变成了CommitLogDispatcherBuildConsumeQueue、CommitLogDispatcherBuildIndex内部类）
消息索引服务（线程）： IndexService
II. DefaultMessageStore.start()会开启的服务（或服务线程）
逻辑队列刷盘服务（线程）： FlushConsumeQueueService
物理队列刷盘服务（线程)： FlushCommitLogService （该服务在初始化commitlog对象时开启）
运行时数据统计服务(线程)： StoreStatsService
从物理队列解析消息重新发送到逻辑队列服务(线程)：ReputMessageService
HA服务： HAService
定时服务：ScheduleMessageService，如定时删除过期文件--cleanFilesPeriodically等。
（注：这些服务对象基本都在初始化DefaultMessageStore实例对象时被创建）
（二） 存储过程
rockemq4.0数据存储的过程与之前的版本存入过程与有很大的不同：
如rocketmq 3.2.4中只有角色为SLAVE的boker会开启ReputMessageService服务。
如rockemq4.0中将之前版本中废除了处理分发消息索引服务DispatchMessageService服务，更改为这两个类CommitLogDispatcherBuildConsumeQueue、CommitLogDispatcherBuildIndex。
如rocketmq 3.2.4可以通过是否开启消息索引功能可以控制是否执行 Index索引。
2.1 rocketmq 3.2.4版本的数据存入过程：
I. commitLog数据存入
- 如果boker角色为MASTER
生产者每写入一条数据，boker端接受到消息后，DefaultMessageStore.putMessage调用Commit.putMessage方法，PutMessage首先要检查一些条件，比如：
1. 每条数据第一写入的broker的属性必须为master，否则回返回PutMessageStatus.SERVICE_NOT_AVAILABLE状态，“message store is slave mode, so putMessage is forbidden ”.
2. 这条msg是否具有被写入的权限，否则回返回PutMessageStatus.SERVICE_NOT_AVAILABLE状态，"message store is not writeable, so putMessage is forbidden ".
3. message topic长度校验
4. message properties长度校验
Commit.putMessage 首先将数据写入到commitlog对应的mapedFile中，每写入一条消息，通过mapedFile.appendMessage追加到MapedFile文件中，当MapedFile写满后，生成一个新的MapedFile，然后向这个MapedFile中追加消息，如此不断 ... ...，这些MapedFile装在MapedFileQueue中。
commitLog中每向mapedFile中写入一个消息后，会返回一个AppendMessageResult对象，根据AppendMessageResult与msg消息信息，生成一个DispatchRequest对象，调用commit的内部类DispatchMessageService.putRequest(dispatchRequest)方法，将写入的消息对应dispatchRequest写入到定义的List<DispatchRequest> requestsWrite列表中。
- 如果boker角色为SLAVE
没有putMessage过程，数据加载通过HAService进行主从同步，同步MASTER中的逻辑队列，向commitLog存入数据。（过程比较复杂，有机会以后单独成文分析）
II. consumeQueue数据存入（indexFile数据存入可选）
- 如果boker角色为MASTER
DispatchMessageService线程在后台一直运行，不断执行doDispatch()
while (!this.isStoped()) {
try {
this.waitForRunning(0);
this.doDispatch();
} catch (Exception e) {
DefaultMessageStore.log.warn(this.getServiceName() + " service has exception. ", e);
}
}
doDispatch()会将requestsWrite列表中的dispatchRequest处理，将它们转换成consumeQueue单元结构对应数据，这些数据追加到consumerQueue对应的MapedFile中。然后添加到consumerQueue的MapedFileQueue中。如果开启了消息索引功能即：isMessageIndexEnable==true,则将requestsWrite列表中的dispatchRequest传给indexService服务，然后indexService将这些消息写入IndexFile中。
- 如果boker角色为SLAVE
由于生产者产生消息不会直接到SLAVE，因此在SLAVE不会执行putMessage逻辑，它主要靠ReputMessageService 服务线程，从物理队列（commitlog）解析消息重新发送到逻辑队列，大致过程为: 从物理队列解析数据，生成dispatchRequest，如果数据正常，则将dispatchRequest传入给DispatchMessageService的List<DispatchRequest> requestsWrite，之后DispatchMessageService处理dispatchRequest的过程与上文一样。
2.2. rocketmq 4.0 版本的数据存入过程
I. commitLog数据存入过程基本不变
不同的是，commit.putMessage过程并不会根据AppendMessageResult与msg消息信息，生成一个DispatchRequest对象，该版本中DispatchRequest对象的生成过程只放在了ReputMessageService中，通过ReputMessageService生成DispatchRequest对象。该版本中ReputMessageService服务线程不像rocketmq 3.2.4中那样只为boker角色为SLAVE单独开设。
II. consumeQueue与indexFile数据存入
rocketmq4.0中此过程的核心服务是ReputMessageService，与之前版本不同的是在rocketmq4.0版本中，consumeQueue与indexFile数据存入的服务线程独立出来了，分别使用CommitLogDispatcherBuildConsumeQueue和CommitLogDispatcherBuildIndex类处理，初始化DefaultMessageStore时，将这两个类存放入dispatcherList列表中：
this.dispatcherList.addLast(new CommitLogDispatcherBuildConsumeQueue()); this.dispatcherList.addLast(new CommitLogDispatcherBuildIndex());
在ReputMessageService服务线程启开后，不断从commitLog中解析数据，生成dispatchRequest ：
DispatchRequest dispatchRequest = DefaultMessageStore.this.commitLog.checkMessageAndReturnSize(result.getByteBuffer(), false, false);
之后向dispatcherList中的所有分发器分发dispatcherList:
DefaultMessageStore.this.doDispatch(dispatchRequest);
即执行：
CommitLogDispatcherBuildConsumeQueue.doDispatch(dispatchRequest)生成consumeQueue数据
CommitLogDispatcherBuildIndex.doDispatch(dispatchRequest)生成IndexFile数据
(三) 数据写入内存小结
即：内存映射
生成commitLog数据的核心接口：
this.commitLog.putMessage(msg)
将数据写入到commitlog对应的MapedFiLe对象中。
生成consumeQueue数据的核心接口：
public void putMessagePositionInfo(DispatchRequest dispatchRequest) {
ConsumeQueue cq = this.findConsumeQueue(dispatchRequest.getTopic(), dispatchRequest.getQueueId());
cq.putMessagePositionInfoWrapper(dispatchRequest);
}
将数据写入到consumeQueue对应的MapedFiLe对象中。
生成IndexFile数据的核心接口：
DefaultMessageStore.this.indexService.buildIndex(request);
将数据写入到IndexFile对应的MapedFiLe对象中。
（四) 内存文件落地 -- 刷盘
上文介绍了数据如何写入到逻辑队列、物理队列、索引的MapedFiLe中，这里介绍如何将逻辑队列、物理队列内存数据持久化到磁盘（索引文件的写入可以在以后的文章中单独分析）。
逻辑队列、物理队列内存文件刷盘方式相同，它们生成的MapedFile文件会放在各自对应的MapedFileQueue对象中，通过刷盘的方式，将MapedFileQueue持久化到物理磁盘上。
初始化DefaultMessageStore的时候会开启： 逻辑队列刷盘服务线程--FlushConsumeQueueService、将ConsumeQueue.mapedFileQueues刷入磁盘；
初始化commitlog对象时开启：物理队列刷盘服务线程--FlushCommitLogService，将commitlog.mapedFileQueues刷入磁盘。
这两个线程会分别将MapedFileQueue持久化到物理磁盘上。
对于commitlog的刷盘策略：
if (FlushDiskType.SYNC_FLUSH == defaultMessageStore.getMessageStoreConfig().getFlushDiskType()) {
this.flushCommitLogService = new GroupCommitService();
} else {
this.flushCommitLogService = new FlushRealTimeService();
}
异步刷盘使用的是FlushRealTimeService，同步刷盘使用的是GroupCommitService
刷盘过程要涉及到MapedFile，MapedFile以及java NIO相关的知识如MappedByteBuffer、FileChannel，可以学到的到东西很多，具体的刷盘实现过程见（下一篇）。