现代的消息队列的主要责任就是存储消息和查询消息，本质上，它们都是分布式存储系统。一个存储系统的性能好坏，最主要的决定因素就是它的存储模型。所有的存储系统中，消息队列的存储可以算是很简单的了，因为消息没有修改的需求，这就使得通过简单的追加写就可以完成消息存储，而如果数据有修改需求，就会导致随机读写，并且在随机写的过程中，可能会引起磁盘内容移动，产生磁盘碎片。相对来说，如果只需要追加写，在设计上要少去大量的工作，还是要幸福不少的
RocketMq在设计上也是遵循了消息文件+索引文件的方式，每种文件都只会追加写，按作用不同分为三类文件：
消息文件commitLog：
一个broker对应一组消息文件commitLog，所有topic的消息都存在commitLog中，写完一个继续写下一个
索引文件consumeQueue：
rocketMq中每个topic对应多个queue，每个queue对应一组索引文件consumeQueue，commitLog中的每条消息在consumeQueue中都对应一条索引数据，索引的key为消费位点，内容为commitLog中消息的位置信息。消费位点表示当前消费到第几条消息了，在rocketMq中，消费者都是按消费位点来broker上拉取消息的，比如consumer1，消费topic1下的queue2中的消息，开始消费时，位点为1，consumer1每消费完一条消息，位点就加1，根据这个递增的位点，就可以拉取到queue2中对应所有消息
索引文件index：
除了满足正常消费的消息索引功能外，还需要满足根据某些关键字查询消息的功能，为了保证查询速度，索引文件是少不了的。这些关键字对应的索引就存在index文件中，一个broker对应一组index文件。rocketMq提供了根据消息msgId、消息key来查询消息的功能，对应的，msgId以及指定的消息key就会被索引，其中msgId是自动生成的，肯定有的，消息key是producer发送消息前设置的，可以设置一组key，每个key都会被索引，不设置就没有
那我们就清楚了，一条消息在broker中存储时，会在commitLog中插入一条消息正文；在consumeQueue中插入一条索引数据，key为消费位点，内容为消息在commitLog文件的位置信息；在index中插入一条或多条索引数据，key为msgId或者指定的消息key，内容为消息在commitLog文件的位置信息
接下来的文章中，我会继续说明两类索引文件的存储结构，看看如何存储索引，以及如何通过索引定位消息