RocketMQ在存储架构上的极致追求
Hollis
共 2962字,需浏览 6分钟
·
2022-02-26 12:56
内容导读:MQ作为一款中间件,就需要承载全公司所有业务系统使用需求,并高效稳定运行。因此,MQ对本身运行效率有着非常苛刻的诉求。
为了实现高效率,其实需要很多方面一起配合来完成。比如存储方式、内存使用、负载均衡等等。
本文就RocketMQ为了实现高效的读写速率在存储架构上所做的努力,进行下阐述。
Part one / 存储结构选型对比
为了更方便的进行数据读写,消息在磁盘底层的文件目录设计,都需要关注和解决什么问题呢:
topic
,特别是允许消费者按topic
进行接收。•再次,分布式集群下的多消费者负载均衡。topic
来拆分文件进行存储,是否可以?topic
都被写入一个文件中,这样,写入时,只要将消息按到达顺序序追加到文件尾部即可,很容易实现顺序写入。topic
拆开多文件存储,还是一整个文件存储做有利有弊,需要按实际需要进行权衡。Part two / RocketMQ的存储方案选择
RocketMQ
存储原始消息选择的是写同一个文件。RocketMQ
一般都是普通业务场景使用居多,生产者和topic
众多,如果都独立开各自存储,每次消息生产的磁盘寻址对性能损耗是非常巨大的。kafka
的文件存储方式,是按topic
拆分成partation
来进行的。是什么样的原因,让kafka
做出了和RocketMQ
相反的选择呢?个人认为,主要还是使用场景的区别,
kafka
被优先选择用来进行大数据处理,相对于业务场景,数据维度的topic
要少很多,并且kafka
的生产者(spark
flume
binlog
等)机器会更加集中,这使得kafka
选择按topic
拆分文件的缺陷不那么突出,而大数据处理更重要的是消息读取,顺序读的优势得以被充分利用。partation
,单cunsumer
的kafka
,性能异常的优秀" 是经常被提及的一个观点,其原因,相信有了上面的分析应该也差不多有结论了。Part three / RocketMQ怎样平衡读性能
RocketMQ
为了保证消息写入效率,在存储结构上选择了顺序写
,势必会对消息的读取和消费带来不便。commitLog
中定位到所需消息的位置。索引
最擅长的事情么?所以,RocketMQ
也为commitLog
创建了索引文件
,并且是区分topic
的结构。RocketMQ 的消息体构成
topic
是业务场景的唯一标识,不可缺少;•queueId
在申请topic的时候确定,关联着消费索引consumerQueue
中的队列ID;•tags
是消息特殊标签,用于业务系统订阅时提前过滤(这个功能真的是太重要了,吃过苦的同学都清楚);•keys
是消息的关键字,构建index索引,用于关键字查询用;•msgBody
是真实消息体;commitLog
里,消息一旦被写入,是不可以更改顺序和内容的。commitLog
规定最大1个G,达到规定大小则写新的一个文件。索引结构和构建过程
consumerQueue
是一种机制,可以让消费端通过queue
和commitLog
之间的检索关系,快速定位到commitLog
里边的具体消息内容,然后拉取进行消费。consumerQueue
按 topic
的不同,被分为不同的queue
,根据queueId
来被消费者订阅和消费;bytes
的记录,由消息在commitLog
中的起始偏移量、消息体占用大小、type
的hash码
三部分构成。可以通过这三个部分快速定位到所需消息位置和类型。commitLog
时,专门的后台服务--putMessageService
,将索引信息分发到 consumerQueue 和index文件里,来构建索引项。消息的消费
CommitOffsetManager
会将当前消费者,针对topic的消费位点进行记录,目的是让下一个或者重新启动单饿消费者记住这个消费位点,不至于重复消费。Part four / 读效率的追求
commitLog
的一部分文件交换到对外内存。然后利用操作系统
的pageCache
技术,在运行过程中把内存里的信息,与磁盘里的文件信息进行同步,或者交换:Part five / 总结
有道无术,术可成;有术无道,止于术
欢迎大家关注Java之道公众号
好文章,我在看❤️
评论