RocketMQ之底层IndexFile存储协议

Posted 2021-09-20 roykingw

index文件的作用我们已经说过，是为了满足根据msgId以及消息key查询消息的需求，每个Broker对应一组indexFile，最大大小为40+50000004+5000000 * 420byte(为啥要这样算，下文会说明)，写完后继续写下一个，indexFile文件名比较特殊，是一串时间戳，这样设计自有妙用

今天要讲的另一类索引文件index(下文简称indexFile)，由于必须以msgId或者生产者指定的消息key作为索引key，所以其结构更复杂一些，分为三部分：文件头indexHeader，一系列槽位slots，真正的索引数据index

从图中可以看出，indexFile结构与hash表很相似，固定数量的slot组成数组，每个slot对应一条index链，index之间通过链表方式组织在一起。slot的值对应当前slot下最新的那个index的序号，index中存储了当前slot下、当前index的前一个index序号，这就把slot下的所有index链起来了

由于indexHeader，slot，index都是固定大小，所以：

公式1：第n个slot在indexFile中的起始位置是这样:40+(n-1)*4

公式2： 第s个index在indexFile中的起始位置是这样:40+5000000*4+(s-1)*20

查询的流程：查询的传入值除了key外，还包含一个时间起始值以及截止值

**为啥还要传时间范围呢？**我们说过，一个indexFile写完一个会继续写下一个，仅仅一个key无法定位到具体的indexFile，时间范围就为了更精确的定位到具体的indexFile，缩小查找的范围，文章最上面，可以看到截图中的indexFile文件名是一个时间戳，根据这个日期就可以定位到传入的日期范围对应在哪个或者哪些indexFile中，很聪明的设计。好了，我们接着说查询流程：

key–>计算hash值–>hash值对500万取余算出对应的slot序号
–>根据40+(n-1)4(公式1)算出该slot在文件中的位置
–>读取slot值，也就是index序号
–>根据40+50000004+(s-1)*20(公式2)算出该index在文件中的位置
–>读取该index–>将key的hash值以及传入的时间范围与index的keyHash值以及timeDiff值进行比对
–>不满足则根据index中的preIndexNo找到上一个index，继续上一步
–>满足则根据index中的phyOffset拿到commitLog中的消息

**为啥比对时还要带上时间范围呢？只比key不行吗？**答案是不行，因为key可能会重复，producer在消息生产时可以指定消息的key，这个key显然无法保证唯一性，那自动生成的msgId呢？也不能保证唯一，你可以去看看msgId的生成规则，

包括当前机器IP+进程号+MessageClientIDSetter.class.getClassLoader()的hashCode值+消息生产时间与broker启动时间的差值+broker启动后从0开始单调自增的int值。

前面三项很明显可能重复，后面两项一个是时间差，一个是重启归零，也可能重复

构建索引的流程：

rocketMq中，两类索引的构建是放在同一个后台任务中ReputMessageService中的，在上一篇文章中已经说明了拿到commitLog中消息的过程，在拿到消息内容后，indexFile的索引构建流程如下：

拿到消息的msgId–>hash值计算–>对500万取余计算对应的slot序号–>根据40+(n-1)*4算出该slot的文件位置–>读取slot值，也就是index序号
–>追加写入一条Index数据，keyHash、phyOffset、timeDiff不用多说，preIndexNo我们说了是前一个index的序号，也就是slot的当前值，如果没有值，说明该slot下没有index
–>更新slot值为插入的index的序号(更新前存的是上一个Index的序号或者空，更新后存的是新插入的Index的序号)
–>更新IndexHeader中的endTimestamp、endPhyOffset、indexCount、hashSlotCount(这一项可能不会更新)

如果消息设置了一个或多个key属性，则重复上面的过程，构建索引