rocket mq的两种索引文件

消息文件commitLog：
一个broker对应一组消息文件commitLog，所有topic的消息都存在commitLog中，写完一个继续写下一个

 

索引文件consumeQueue：
rocketMq中每个topic对应多个queue，每个queue对应一组索引文件consumeQueue，commitLog中的每条消息在consumeQueue中都对应一条索引数据，索引的key为消费位点，内容为commitLog中消息的位置信息。消费位点表示当前消费到第几条消息了，在rocketMq中，消费者都是按消费位点来broker上拉取消息的，比如consumer1，消费topic1下的queue2中的消息，开始消费时，位点为1，consumer1每消费完一条消息，位点就加1，根据这个递增的位点，就可以拉取到queue2中对应所有消息

索引文件index：
可以根据key查询(key + 时间范围)

为了满足根据msgId以及消息key查询消息的需求，每个Broker对应一组indexFile，最大大小为40+5000000*4+5000000 * 4*20byte(为啥要这样算，下文会说明)，写完后继续写下一个，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+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值，前面三项很明显可能重复，后面两项一个是时间差，一个是重启归零，也可能重复