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属性,则重复上面的过程,构建索引