index文件的作用我们在rocketMq存储模型_概述一文中已经说过，是为了满足根据msgId以及消息key查询消息的需求，每个Broker对应一组indexFile，最大大小为40+5000000*4+5000000 * 4*20byte(为啥要这样算，下文会说明)，写完后继续写下一个，indexFile文件名比较特殊，是一串时间戳，这样设计自有妙用
上一篇文章讲述了consumequeue这类索引文件的结构及读写过程，因为consumequeue以一个单调递增的int数字为索引，所以其结构非常简单，今天要讲的另一类索引文件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+5000000*4+(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属性，则重复上面的过程，构建索引