RocketMQ在存储架构上的极致追求

简介: 内容导读:MQ作为一款中间件,就需要承载全公司所有业务系统使用需求,并高效稳定运行。因此,MQ对本身运行效率有着非常苛刻的诉求。为了实现高效率,其实需要很多方面一起配合来完成。比如存储方式、内存使用、负载均衡等等。本文就RocketMQ为了实现高效的读写速率在存储架构上所做的努力,进行下阐述。

内容导读:MQ作为一款中间件,就需要承载全公司所有业务系统使用需求,并高效稳定运行。因此,MQ对本身运行效率有着非常苛刻的诉求。

为了实现高效率,其实需要很多方面一起配合来完成。比如存储方式、内存使用、负载均衡等等。

本文就RocketMQ为了实现高效的读写速率在存储架构上所做的努力,进行下阐述。


Part one / 存储结构选型对比


为了更方便地进行数据读写,消息在磁盘底层的文件目录设计,都需要关注和解决什么问题呢:

•首先,最基本的,是消息原始记录的写入和存储,且速率要快。•其次,要可以区分topic ,特别是允许消费者按topic进行接收。•再次,分布式集群下的消费者负载均衡。

那么问题来了,消息文件该怎么设计呢?

如果按topic来拆分文件进行存储,是否可以?


•缺点:生产者写入时选择对应的文件来写入。当数据量逐渐增大之后,定位查询文件地址,对磁盘的寻址所带来的性能损耗,将不再可以忽略。•优点:在消费时,可以直接加载相关文件进行读取,不会产生随机寻址。

如果用一整个文件来存消息呢?


•优点:所有的topic都被写入一个文件中,这样,写入时,只要将消息按到达顺序序追加到文件尾部即可,很容易实现顺序写入。•缺点:消费时,需要根据辅助信息来在文件中定位消息,会产生随机读取,损耗性能。

因此,不管是按topic拆开多文件存储,还是一整个文件存储做有利有弊,需要按实际需要进行权衡。


Part two / RocketMQ的存储方案选择


RocketMQ存储原始消息选择的是写同一个文件。

image.png

生产者将消息顺序写入commitLog文件

究其原因,是由于RocketMQ一般都是普通业务场景使用居多,生产者和topic众多,如果都独立开各自存储,每次消息生产的磁盘寻址对性能损耗是非常巨大的。

旁证侧引: kafka的文件存储方式,是按topic拆分成partation来进行的。是什么样的原因,让kafka做出了和RocketMQ相反的选择呢?

个人认为,主要还是使用场景的区别,kafka被优先选择用来进行大数据处理,相对于业务场景,数据维度的topic要少很多,并且kafka的生产者(sparkflume binlog等)机器会更加集中,这使得kafka选择按topic拆分文件的缺陷不那么突出,而大数据处理更重要的是消息读取,顺序读的优势得以被充分利用。"单partation,单cunsumer的kafka,性能异常的优秀" 是经常被提及的一个观点,其原因,相信有了上面的分析应该也差不多有结论了。


Part three / RocketMQ怎样平衡读性能


从第一部分的存储方案对比可以知道,RocketMQ为了保证消息写入效率,在存储结构上选择了顺序写,势必会对消息的读取和消费带来不便。

那么,它是怎么来平衡消费时的读取速率的呢?

关键问题是,找到一种途径,可以快速的在commitLog中定位到所需消息的位置。

从一堆数据中,快速定位想要的数据,这不是索引最擅长的事情么?所以,RocketMQ也为commitLog创建了索引文件,并且是区分topic的结构。

image.png

存储架构和存储设备构建链路示意图


RocketMQ 的消息体构成


image.png

消息体元素构成

•topic 是业务场景的唯一标识,不可缺少;•queueId 在申请topic的时候确定,关联着消费索引consumerQueue中的队列ID;•tags 是消息特殊标签,用于业务系统订阅时提前过滤(这个功能真的是太重要了,吃过苦的同学都清楚);•keys 是消息的关键字,构建index索引,用于关键字查询用;•msgBody 是真实消息体;

消息由发布者发布,并依次的、顺序的写到commitLog里,消息一旦被写入,是不可以更改顺序和内容的。commitLog规定最大1个G,达到规定大小则写新的一个文件。


索引结构和构建过程


image.png

consumerQueue结构和创建过程

consumerQueue 是一种机制,可以让消费端通过queue和commitLog之间的检索关系,快速定位到commitLog里边的具体消息内容,然后拉取进行消费。


consumerQueue 按 topic的不同,被分为不同的queue,根据queueId来被消费者订阅和消费;


其中每个索引项是一个固定大小为20bytes的记录,由消息在commitLog中的起始偏移量、消息体占用大小、type的hash码三部分构成。可以通过这三个部分快速定位到所需消息位置和类型。

而上述索引的构建过程,是在消息被写入commitLog时,专门的后台服务--putMessageService,将索引信息分发到 consumerQueue 和index文件里,来构建索引项。


建索引的过程,实际上是一种分而治之思维的落地,除了索引,还有redis中的各种指标维护,核心是 分散压力到每次请求,避免了大规模集中计算。


消息的消费


消费者对应consumerQueue不一定是一对一的,因此,怎么来让每个新的消费者来了不会重复消费呢?

image.png

offset消费位点记录

在消息成功被拉取并消费时,后台任务CommitOffsetManager 会将当前消费者,针对topic的消费位点进行记录,目的是让下一个或者重新启动单位消费者记住这个消费位点,不至于重复消费。

因此,整个文件目录就一目了然了:

image.png


Part four / 读效率的追求


虽然通过上述文件存储结构的分析,我们知道,消费者可以根据索引文件中的索引项来快速定位, 但事实上,消息的发布和消费,不可能直接针对磁盘进行读写操作的,这样效率会非常非常低。


实际上,我们的操作基本是针对一块内存进行操作的


利用NIO的内存映射机制,我们将commitLog的一部分文件交换到对外内存。然后利用操作系统的pageCache技术,在运行过程中把内存里的信息,与磁盘里的文件信息进行同步,或者交换:

•消息发布者,在发布消息的时候,首先把消息添加到内存里,然后根据刷盘的配置可以来指定是同步刷盘还是异步刷盘,来将内存中的数据同步到磁盘上。•消息的消费者,在消费消息的时候,大多数情况下,会直接命中到内存上,不会进行磁盘读取,但极个别的情况下,需要消费的消息,在内存中没法找到,这时候,就需要用换页技术,将相关的信息,拉取到内存中。为什么是相关信息,而不是需要什么拉取什么?这是有一个机制,来保证潜在的即将被消费的信息直接换入内存,来提交效率。

image.png

摘自:Qcon大会 RocketMQ分享资料


Part five / 总结


整体一套处理流程看下来,其实我们可以看到很多熟悉的身影,比如Mysql的索引,redis的统计信息记录等等,都非常相似。

其实,我们可以这么认为:对于信息存储和查询的处理方案大都如出一辙,只要把握住最核心的部分,然后根据实际业务诉求进行适配优化,基本都是可以达到期望的结果的。

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
相关文章
|
15天前
|
消息中间件 存储 Java
RocketMQ(一):消息中间件缘起,一览整体架构及核心组件
【10月更文挑战第15天】本文介绍了消息中间件的基本概念和特点,重点解析了RocketMQ的整体架构和核心组件。消息中间件如RocketMQ、RabbitMQ、Kafka等,具备异步通信、持久化、削峰填谷、系统解耦等特点,适用于分布式系统。RocketMQ的架构包括NameServer、Broker、Producer、Consumer等组件,通过这些组件实现消息的生产、存储和消费。文章还提供了Spring Boot快速上手RocketMQ的示例代码,帮助读者快速入门。
|
3月前
|
消息中间件 存储 Java
RabbitMQ 在微服务架构中的高级应用
【8月更文第28天】在微服务架构中,服务之间需要通过轻量级的通信机制进行交互。其中一种流行的解决方案是使用消息队列,如 RabbitMQ,来实现异步通信和解耦。本文将探讨如何利用 RabbitMQ 作为服务间通信的核心组件,并构建高效的事件驱动架构。
120 2
|
3月前
|
存储 缓存 前端开发
Django 后端架构开发:存储层调优策略解析
Django 后端架构开发:存储层调优策略解析
50 2
|
3月前
|
消息中间件 存储 数据库
深入学习RocketMQ的底层存储设计原理
文章深入探讨了RocketMQ的底层存储设计原理,分析了其如何通过将数据和索引映射到内存、异步刷新磁盘以及消息内容的混合存储来实现高性能的读写操作,从而保证了RocketMQ作为一款低延迟消息队列的读写性能。
|
21天前
|
存储 监控 分布式数据库
百亿级存储架构: ElasticSearch+HBase 海量存储架构与实现
本文介绍了百亿级数据存储架构的设计与实现,重点探讨了ElasticSearch和HBase的结合使用。通过ElasticSearch实现快速检索,HBase实现海量数据存储,解决了大规模数据的高效存储与查询问题。文章详细讲解了数据统一接入、元数据管理、数据一致性及平台监控等关键模块的设计思路和技术细节,帮助读者理解和掌握构建高性能数据存储系统的方法。
百亿级存储架构: ElasticSearch+HBase 海量存储架构与实现
|
2月前
|
消息中间件 弹性计算 运维
云消息队列RabbitMQ 版架构优化评测
云消息队列RabbitMQ 版架构优化评测
62 6
|
2月前
|
存储 监控 数据可视化
SLS 虽然不是直接使用 OSS 作为底层存储,但它凭借自身独特的存储架构和功能,为用户提供了一种专业、高效的日志服务解决方案。
【9月更文挑战第2天】SLS 虽然不是直接使用 OSS 作为底层存储,但它凭借自身独特的存储架构和功能,为用户提供了一种专业、高效的日志服务解决方案。
136 9
|
3月前
|
网络协议 Java 物联网
MQTT(EMQX) - SpringBoot 整合MQTT 连接池 Demo - 附源代码 + 在线客服聊天架构图
MQTT(EMQX) - SpringBoot 整合MQTT 连接池 Demo - 附源代码 + 在线客服聊天架构图
711 2
|
3月前
|
消息中间件 Java RocketMQ
微服务架构师的福音:深度解析Spring Cloud RocketMQ,打造高可靠消息驱动系统的不二之选!
【8月更文挑战第29天】Spring Cloud RocketMQ结合了Spring Cloud生态与RocketMQ消息中间件的优势,简化了RocketMQ在微服务中的集成,使开发者能更专注业务逻辑。通过配置依赖和连接信息,可轻松搭建消息生产和消费流程,支持消息过滤、转换及分布式事务等功能,确保微服务间解耦的同时,提升了系统的稳定性和效率。掌握其应用,有助于构建复杂分布式系统。
63 0
|
4月前
|
存储 运维 数据库
业务系统架构实践问题之业务模型和存储模型解耦的重要性问题如何解决
业务系统架构实践问题之业务模型和存储模型解耦的重要性问题如何解决

热门文章

最新文章