RocketMQ原理解析-broker 6.索引服务

1索引结构

IndexFile 存储具体消息索引的文件,文件的内容结构如图:


索引文件由索引文件头IndexHeader, 槽位Slot和消息的索引内容三部分构成

 

IndexHeader:索引文件头信息40个字节的数据组成

 

 

 beginTimestamp    8位long类型,索引文件构建第一个索引的消息落在broker的时间

endTimestamp         8位long类型,索引文件构建最后一个索引消息落broker时间

beginPhyOffset         8位long类型,索引文件构建第一个索引的消息commitLog偏移量

endPhyOffset            8位long类型,索引文件构建最后一个索引消息commitLog偏移量

hashSlotCount    4位int类型,构建索引占用的槽位数(这个值貌似没有具体作用)

indexCount                4位int类型,索引文件中构建的索引个数

 

槽位slot, 默认每个文件配置的slot个数为500万个,每个slot是4位的int类型数据

计算消息的对应的slotPos=Math.abs(keyHash)%hashSlotNum

消息在IndexFile中的偏移量absSlotPos = IndexHeader.INDEX_HEADER_SIZE + slotPos *HASH_SLOT_SIZE

Slot存储的值为消息个数索引

 

消息的索引内容是20位定长内容的数据


         4位int值, 存储的是key的hash值

         8位long值     存储的是消息在commitlog的物理偏移量phyOffset

         4位int值        存储了当前消息跟索引文件中第一个消息在broker落地的时间差

         4位int值        如果存在hash冲突,存储的是上一个消息的索引地址

 

2. 索引服务IndexService线程

1.      索引配置:hashSlotNum哈希槽位个数、indexNum存储索引的最大个数、storePath索引文件indexFile存储的路径

2.      Load broker启动的时候加载本地IndexFile,

如果是异常启动删除之后storeCheckPoint文件,因为commitLog根据storeCheckPoint会重建之后的索引文件,

3.      Run方法,任务从阻塞队列中获取请求构建索引

4.      queryOffset 根据topic key 时间跨度来查询消息

倒叙遍历所有索引文件

每一个indexfile存储了第一个消息和最后一个消息的存储时间,根据传入时间范围来判断索引是否落在此索引文件

 

3. 构建索引服务

分发消息索引服务将消息位置分发到ConsumeQueue中后,加入IndexService的LinkedBlockingQueue队列中,IndexService通过任务向队列中获取请求来构建索引

剔除commitType或者rollbackType消息,因为这两种消息都有对应的preparedType的消息

构建索引key(topic + "#" + key)

根据key的hashcode计算槽位,即跟槽位最大值取余数

计算槽位在indexfile的具体偏移量位置

根据槽位偏移量获取存储的上一个索引

计算消息跟文件头存储开始时间的时间差

根据消息头记录的存储消息个数计算消息索引存储的集体偏移量位置

写入真正的索引,内容参考上面索引内容格式

将槽位中的更新为此消息索引

更新索引头文件信息

 

 

4.  Broker与client(comsumer ,producer)之间的心跳

一:Broker接收client心跳ClientManageProcessor处理client的心跳请求

1.      构建ClientChannelInfo对象

1)  持有channel对象,表示与客户端的连接通道

2)  ClientID表示客户端

…..

2.      每次心跳会更新ClientChannelInfo的时间戳,来表示client还活着

3.      注册或者更新consumer的订阅关系(是以group为单位来组织的, group下可能有多个订阅关系)

4.      注册producer,其实就是发送producer的group(这个在事物消息中才有点作用)

二:ClientHouseKeepingService线程定时清除不活动的连接

1)  ProducerManager.scanNotActiveChannel    默认两分钟producer没有发送心跳清除

2)  ConsumerManager.scanNotActiveChannel   默认两份中Consumer没有发送心跳清除

 

5. Broker与namesrv之间的心跳

1)  namesrv接收borker心跳DefaultRequestProcessor的REGISTER_BROKE事件处理,

(1)      注册broker的topic信息

(2)      构建或者更新BrokerLiveInfo的时间戳

NamesrvController初始化时启动线程定时调用RouteInfoManger的scanNotActiveBroker方法来定时不活动的broker(默认两分钟没有向namesrv发送心跳更新时间戳的)

  • 0
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值