消息生产过程
- producer发送消息之前,会从Nameserver获取该topic的路由表信息
- NS返回topic的路由表和broker列表
- producer通过指定的Queue选择策略,从Queue列表中选择一个,用于后续存储消息
- producer对消息的一些特殊处理,如消息本身大于4M压缩
- Producer向选择出的Queue对应的Broker发送RPC请求,将消息发送给该Queue
- 路由表:MQClientInstance#topicRouteTable源码中底层是一个Map,key为topic名称,Value是一个QueueData实例列表.QueueData是一个broker中该topic所有Queue对应一个QueueData. 涉及到该topic的broker,一个broker对应一个QueueData. QueueData中包含brokerName.
- Broker列表:MQClientInstance#brokerAddrTable底层也是一个Map.key为brokerName,value为BrokerData. 一套brokerName名称相同的Master-Slave小集群对应一个BrokerData. BrokerData包含brokerName和一个map.该map的key为brokerId,value为broker对应地址. brokderId为0表示为master非0表示slave
Queue路由选择算法
- 轮询算法: 默认 保证每一个queue均匀获取消息,可能存在的问题某些broker上的queue投递延迟严重,从而导致producer缓存队列出现大量消息积压,影响消息的投递性能
- 最小投递延迟算法: 该算法会统计每次消息投递的消息延迟,然后统计出结果将消息投递到延迟最小的Queue.如延迟相同采用轮询投递.该算法可以有效提高消息投递性能. 存在的问题在于可能出现Queue的分配不均匀,导致延迟小的queue存在大量的消息,从而对该queue的消费者压力增大,降低消息的消费能力,导致MQ中的消息堆积
消息存储
RocketMQ消息存储在本地文件系统中,默认在当前用户家目录下的store目录中
-rw-r--r--. 1 root root 0 Jul 13 08:28 abort
-rw-r--r--. 1 root root 4096 Jul 13 08:28 checkpoint
drwxr-xr-x. 2 root root 34 Apr 30 08:30 commitlog
drwxr-xr-x. 2 root root 280 Jul 13 08:28 config
drwxr-xr-x. 9 root root 199 Apr 29 18:30 consumequeue
drwxr-xr-x. 2 root root 31 Apr 29 18:14 index
-rw-r--r--. 1 root root 4 Jul 13 08:28 lock
- abort: broker启动之后自动创建,正常关闭broker会自动删除.如果在没有启动Broker出现这个文件说明之前broker非正常关闭
- checkpoint: 存储着commitlog consumequeue index文件的最后刷盘时间戳
- commitlog: 消息真实存储的文件
- config: broker运行期间的配置数据
- consumequeue: 队列信息存放在该目录
- Index: 存在消息索引文件IndexFile
- lock: 运行期间使用的全局锁资源
commitlog
[root@node1 store]# cd commitlog/
[root@node1 commitlog]# ll
total 56
-rw-r--r--. 1 root root 1073741824 Apr 29 18:44 00000000000000000000
又称mappedFile.当前broker中所有信息都会落盘到这些mappedFile文件中.每一个mappedFile文件大小为1G(>=1G),文件名由20位十进制数构成,表示当前文件的第一条消息的起始位置偏移量
- broker中所有的mappedFile文件中的commitlog offset是连续的
- 一个broker只会包含一个commitlog目录,所有的mappedFile文件都是存放该目录中.broker存放时没有按照topic进行分类存放
- mappedFile文件是顺序写
消息单元
mappedFile文件由多个消息单元组成
| 名称 | 描述 |
|---|---|
| MsgLen | 消息长度 |
| PhysicalOffset | 消息物理地址 |
| Body | 消息体 |
| BodyLength | 消息体长度 |
| Topic | 主题 |
| TopicLength | 主题长度 |
| BornHost | 生产者信息 |
| BornTimestamp | 消息发送时间戳 |
| QueueId | 消息所在队列Id |
| QueueOffset | 消息在Queue中存储的偏移量 |
consumerqueue
[root@node1 consumequeue]# ll
total 0
drwxr-xr-x. 3 root root 15 Apr 29 18:27 %RETRY%pointGroup
drwxr-xr-x. 6 root root 42 Apr 29 18:20 RMQ_SYS_TRACE_TOPIC
drwxr-xr-x. 3 root root 15 Apr 29 18:14 RMQ_SYS_TRANS_HALF_TOPIC
drwxr-xr-x. 3 root root 15 Apr 29 18:25 RMQ_SYS_TRANS_OP_HALF_TOPIC
drwxr-xr-x. 5 root root 33 Apr 29 18:27 SCHEDULE_TOPIC_XXXX
drwxr-xr-x. 3 root root 15 Apr 29 18:30 TRANS_CHECK_MAX_TIME_TOPIC
drwxr-xr-x. 4 root root 24 Apr 29 18:29 txMsg
[root@node1 consumequeue]# cd txMsg/
[root@node1 txMsg]# ll
total 0
drwxr-xr-x. 2 root root 34 Apr 29 18:29 0
drwxr-xr-x. 2 root root 34 Apr 29 18:25 2
RocketMQ为每一个topic在~/store/consumequeue中创建一个目录,目录名为topic的名称.该目录下再会为该topic的Queue创建一个目录,目录名为Queue的Id.每个目录中存放了若干个consumequeue文件.
consumequeue文件是commitlog的索引文件可以定位到具体的消息
consume文件中每一条记录成为索引条目
每一个consumequeue文件中可以包含30W个索引条目,每一个索引条目大小固定,固定20个字节
一个consumequeue文件中所有消息的topic一定相同,但是每条消息的tag可能是不同的
| 名称 | 描述 |
|---|---|
| CommitLog offset | 消息在mappedFile文件中的偏移量CommitLog Offset |
| Msg length | 消息长度 |
| TagHashCode | 消息Tag的hashcode值 |
文件读写
消息写入
- broker根据queueId,获取该消息对应索引条目要在consumerqueue中写入偏移量 QueueOffset
- 将queueId queueOffset等数据与消息一起封装成消息单元
- 将消息单元写入commitLog
- 同时形成消息的索引条目
- 将索引条目分发到对应的consumequeue中
消息拉取
- consumer获取到消息所在Queue的消费偏移量offset,计算出其要消费的消息的offset
- 消费进度,consumer对某一个Queue的消费offset,消费到了第几条消息
- 即将消费offset = 消费offset+1
- consumer向broker发送拉取请求,其中会包含要拉取消息的queue 消息offset 和消息的tag
- broker计算在该consumequeue中的queueOffset
- queueOffset = 消息offset * 20 (因为一个索引条目固定20字节)
- 从queueOffset开始往后查找第一个指定tag的索引条目
- 解析该索引条目的前8个字节,即解析commitlog offset和 消息长度,即可定位到该消息在commitlog中commitlog offset
- 从对应的commitlog offset中读取消息单元发送给consumer
高性能分析
- RocketMQ对文件读写使用了mmap零拷贝技术,将对文件的操作转化为直接对内存地址的操作
- 顺序写 consumequeue和commitlog文件都是采用了顺序存放
- pagecache预读机制 是的consumequeue文件的读取几乎接近内存读取
pageCache机制,页缓存技术,OS对文件的缓存机制,加速文件读写. 一般来说,程序对文件的顺序读写速度几乎接近与内存读写速度,主要是因为OS使用了pagecache技术对读写访问操作进行了优化,将一部分的内存用于PageCache
- 写: OS会将数据写入PageCache中,随后以异步方式由page dirty push 内存线程将cache中的数据刷盘到物理磁盘
- 读: 首先从pagecache中读取,未命中,OS从物理磁盘上加载数据到pagecache中,并会顺序将起相邻的数据块的数据一并进行预读取操作
RocketMQ中可能会影响性能的是对commitlog文件的读取。因为对commitlog文件来说，读取消息时会产生大量的随机访问，而随机访问会严重影响性能。不过，如果选择合适的系统IO调度算法，比如设置调度算法为Deadline（采用SSD固态硬盘的话），随机读的性能也会有所提升
kafka与RocketMQ对比
- RocketMQ的commitlog+consumequeue 类似与kafka中的parttion分区目录,mappedFile文件类似与kafka的segement
- kafka中的topic分割成了一个或多个parttion, parttion是一个物理概念,对应为topic目录下的一个或多个目录. 每个parttion中包含了若干segment存放具体消息
- kafka没有二级分类标签tag概念
- kafka消息存放结构: topic -> partition -> segment
IndexFile
RocketMQ提供了根据Key进行消息查询功能.主要是通过store目录下的index子目录中的IndexFile进行索引快速查询. 索引的数据是消息中包含了Key的消息,被发送到broker时写入,如果消息中没有包含Key,则不会写入
每个broker会包含一组indexFile,每个IndexFile都以一个时间戳命名(创建时的时间戳).每个IndexFile由:IndexHeader slots indexes索引数据.每个Indexfile包含500W个slot,每个slot可能被挂载多个Index索引单元
IndexHeader固定40字节
- beginTimestamp: 该Indexfile第一条消息存储时间
- endTimestamp: 该Indexfile最后一条消息存储时间
- beginPhyoffset: 该indexfile第一条消息在commitlog中的偏移量
- endPyhoffset: 该indexfile最后消息在commitlog中的偏移量
- hashSlotCount: 已经填充有Index的slot数量,并不是每个slot槽下都挂载有index索引单元，这里统计的是所有挂载了index索引单元的slot槽的数量
- indexCount: 包含的索引单元个数(统计当前indexFile中所有slot下挂载的所有Index索引单元之和)
indexFile中slot与index索引单元关系
key的hash值%500W得到具体的slot槽位,然后将该slot的值改为index索引单元的IndexNo,根据该IndexNo可以计算出该Index单元在indexfile中的位置.
为了解决hash冲突,每个索引单元增加的preIndexNo,用于记录该索引单元下的前一个索引单元.slot中始终存放的是最新的索引单元的IndexNo,通过slot的indexNo找到最新的索引单元再通过索引单元的preIndexNo去找之前的所有Index索引单元
indexNo是一个在indexFile中的流水号，从 0 开始依次递增。即在一个indexFile中所有indexNo是以此递增的。indexNo在index索引单元中是没有体现的，其是通过indexes中依次数出来的
索引单元
- keyHash: 消息中指定的key的hash值
- phyOffset: 当前key的消息在commitlog偏移量
- timeDiff: 当前Key对应的消息的存储时间与当前indexFile文件创建时间的时间差
- preIndexNo: 当前slot下该索引单元的前一个索引单元的indexNo
indexFile的创建
根据业务Key查询时,查询条件除了Key之外,还需要指定一个查询时间戳,表示查询不大于该时间戳的最新消息.此时indexFile以时间戳命名的话就可以简化查询
index文件创建时机
- 当第一条带Key消息发送的时候,没有IndexFile,此时会创建第一个Indexfile
- 当一个Indexfile挂载的索引单元超过2000W时,会创建新的indexFile. 当带Key消息发送过来之后,系统找到最新的IndexFile,并从indexHeader中获取到IndexCount如果大于2000W则创建
通过Key的查询流程
-
计算消息key的slot槽位序号 (找slot序号)
slot = hash(msg.key) % 500W -
计算slot序号为n的slot在Indexfile的起始位置 (定位slot)
slot(n) = 40 + (n - 1) * 4
40: indexHeader的位置
n-1: slot位置
4 一个slot占4字节
-
计算indexNo为m的index在indexFile中的位置 (定位索引单元)
index(m)位置 = 40 + 500w * 4 + (m - 1) * 20 (式子3)
40: indexHeader的位置
500w * 4: 500w个slot 每个slot 4字节
(m-1)*20: m为索引单元的位置 20 一个索引单元固定20字节
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
