第十章-Broker-存储文件

前面已经提到，可以把Broker想像成一个消息存储的仓库，那么这个仓库就得提供消息存储的场所，这个场所就是 commitlog 文件，broker 接收到的所有消息都要存储在这个文件中。那么，是不是有这一个文件就够了呢，答案是否定的，因为消息是要被消费的，为了方便消费，就得把消息拆分开来，转移到方便消息的地方，这个地方就是消费队列，我们依此慢慢推理。如果转移消息本身，就会造成消息的重复存储以及消息的同步安全问题，那么是不是可以只转移消息的索引呢，也就是说消费队列只存储能找到消息的 commitlog 的索引，这样就解决问题了，至此 ConsumeQueue 的概念也出来了，跟 commitlog 一样，也是维护一整套文件。其实，到这里已经可能完成正常的消息收发操作，但是，对消息的搜索操作，就无法满足，这就引入另一个概念：索引，就是满足用户对特定消息的查询处理，这就需要用到另一个文件：indexFile。整个 Broker 的存储就是围绕这三个文件来实现的，本章节的内容也就是针对这3个文件来讲解。接下来用一张图来说明他们的结构及关系，看图10-1

图10-1

上图已经把commitlog、consumeQueue、indexFile三种文件的存储方式、结构和关系都描述的非常清晰了。这三个文件的写入顺序是，当broker收到消息后，首先将消息写入commitlog文件中，然后再通过分发的形式，分别像consumeQueue和indexFile文件写该消息对应的内容（这个内容主要指能够在commitlog文件中快速定位到消息内容的辅助数据）。接下来，我们要解决的就是以下几个问题：

1、文件什么时候创建？怎么创建？怎么命名？

2、文件结构？

3、文件内容什么时候写入？由谁来触发？

4、文件存储会不会膨胀？如果会，怎么办？

5、文件写入失败怎么办？三个文件中，部分文件写入失败怎么办？

这些问题的答案，都将在后续章节对源码解析的过程中解答。本章内容就此结束，看起来很短，实际上，精华都在图10-1中，说实话，画这个图很费劲的。