系列
概述
这篇文章主要是想讲清楚rocketMq中index的存储和查询功能，着重分为存储和查询两个点进行讲解，这里需要支持的是这篇博文还是参考了很多互联网人的已有成果（就是站在了前人的肩膀上），参考文章会在文章引用中列出。
index数据结构
index的数据结构总共包括header，slot，index总计3个部分组成，各个部分的格式如下图所示，其中slot可以保存500万slot，index部分可以保存2000万index。
header结构
说明：
1. beginTimestamp : 该索引文件的第一个消息(Message)的存储时间(落盘时间) 物理位置(pos: 0-7) 8bytes
2. endTimestamp : 该索引文件的最后一个消息(Message)的存储时间(落盘时间) 物理位置(pos: 8-15) 8bytes
3. beginPhyoffset : 该索引文件第一个消息(Message)的在CommitLog(消息存储文件)的物理位置偏移量(可以通过该物理偏移直接获取到该消息) 物理位置(pos: 16-23) 8bytes
4. endPhyoffset : 该索引文件最后一个消息(Message)的在CommitLog(消息存储文件)的物理位置偏移量 (pos: 24-31) 8bytes
5. hashSlotCount : 该索引文件目前的hash slot的个数 (pos: 32-35) 4bytes
6. indexCount : 该索引文件目前的索引个数 (pos: 36-39) 4bytes
说明：
slot每个节点保存当前已经拥有多少个index数据了。
说明：
1. key hash value: message key的hash值
2. phyOffset: message在CommitLog的物理文件地址, 可以直接查询到该消息(索引的核心机制)
3. timeDiff: message的落盘时间与header里的beginTimestamp的差值(为了节省存储空间，如果直接存message的落盘时间就得8bytes)
4. prevIndex: hash冲突处理的关键之处, 相同hash值上一个消息索引的index(如果当前消息索引是该hash值的第一个索引，则prevIndex=0, 也是消息索引查找时的停止条件)，每个slot位置的第一个消息的prevIndex就是0的。
存储过程
1、首先判断下index是否查处最大限制，没有超出则继续执行
2、根据key计算hash值%hashSlotNum得出具体安放slot的位置
3、计算真正放置slot的物理位置偏移
4、生成index对象并按照格式放置所有字段，其中我们注意一下slotValue，该hash位置第一次放置的时候slotValue的值为0，后面放置的slotValue是前一次index的位移个数。
5、增加index的所有计数值
检索过程
1、先计算key对应的hash值并找到对应的slot
2、根据slot找到该slot上最新一个index的数据并开始进行回溯
3、每个index都对比时间戳判断是否符合要求
4、根据每个index的前置index来获取前一个index的值
