性能文章>RocketMQ在存储架构上的极致追求>

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

224217

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

Part one / 存储结构选型对比

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

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

那么问题来了,消息文件该怎么设计呢?
如果按topic来拆分文件进行存储,是否可以?

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

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

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

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

Part two / RocketMQ的存储方案选择

RocketMQ存储原始消息选择的是写同一个文件。
生产者将消息顺序写入commitLog文件
究其原因,是由于 RocketMQ一般都是普通业务场景使用居多,生产者和 topic众多,如果都独立开各自存储,每次消息生产的磁盘寻址对性能损耗是非常巨大的。
旁证侧引:
kafka的文件存储方式,是按 topic拆分成 partation来进行的。是什么样的原因,让 kafka做出了和 RocketMQ相反的选择呢?

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

Part three / RocketMQ怎样平衡读性能

从第一部分的存储方案对比可以知道, RocketMQ为了保证消息写入效率,在存储结构上选择了 顺序写,势必会对消息的读取和消费带来不便。
那么,它是怎么来平衡消费时的读取速率的呢?
关键问题是,找到一种途径,可以快速的在commitLog中定位到所需消息的位置。
从一堆数据中,快速定位想要的数据,这不是 索引最擅长的事情么?所以, RocketMQ也为 commitLog创建了 索引文件,并且是区分 topic的结构。
存储架构和存储构建链路示意图

RocketMQ 的消息体构成

消息体元素构成

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

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

索引结构和构建过程

consumerQueue结构和创建过程
consumerQueue 是一种机制,可以让消费端通过 queuecommitLog之间的检索关系,快速定位到 commitLog里边的具体消息内容,然后拉取进行消费。
consumerQueue 按  topic的不同,被分为不同的 queue,根据 queueId来被消费者订阅和消费;
其中每个索引项是一个固定大小为20 bytes的记录,由消息在 commitLog中的起始偏移量、消息体占用大小、 typehash码三部分构成。可以通过这三个部分快速定位到所需消息位置和类型。
而上述索引的构建过程,是在消息被写入 commitLog时,专门的后台服务-- putMessageService,将索引信息分发到 consumerQueue 和index文件里,来构建索引项。
建索引的过程,实际上是一种分而治之思维的落地,除了索引,还有redis中的各种指标维护,核心是 分散压力到每次请求,避免了大规模集中计算。

消息的消费

消费者对应consumerQueue不一定是一对一的,因此,怎么来让每个新的消费者来了不会重复消费呢?
offset消费位点记录
在消息成功被拉取并消费时,后台任务 CommitOffsetManager 会将当前消费者,针对topic的消费位点进行记录,目的是让下一个或者重新启动单饿消费者记住这个消费位点,不至于重复消费。
因此,整个文件目录就一目了然了:

Part four / 读效率的追求

虽然通过上述文件存储结构的分析,我们知道,消费者可以根据索引文件中的索引项来快速定位, 但事实上,消息的发布和消费,不可能直接针对磁盘进行读写操作的,这样效率会非常非常低。
实际上,我们的操作基本是针对一块内存进行操作的 。
利用NIO的内存映射机制,我们将 commitLog的一部分文件交换到对外内存。然后利用 操作系统pageCache技术,在运行过程中把内存里的信息,与磁盘里的文件信息进行同步,或者交换:

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

摘自:Qcon大会 RocketMQ分享资料

Part five / 总结

整体一套处理流程看下来,其实我们可以看到很多熟悉的身影,比如Mysql的索引,redis的统计信息记录等等,都非常相似。
其实,我们可以这么认为:对于信息存储和查询的处理方案大都如出一辙,只要把握住最核心的部分,然后根据实际业务诉求进行适配优化,基本都是可以达到期望的结果的。
分类:
请先登录,再评论

的确,场景不同需求不同!

2月前

为你推荐

大数据中台之Kafka,到底好在哪里?
Hello,大家好,今天给大家分享一个大数据里面很火的技术——Kafka,Kafka 是一个分布式的消息系统,其高性能在圈内很出名。本人阅读过多个大数据生态的开源技术的源码,个人感觉 Kafka 的源
什么?搞不定Kafka重复消费?
今天我们聊一个话题,如何保证 Kafka 消息不重复消费?在使用 Kafka 的时候一般都会设置重试的次数,但是因为网络的一些原因,设置了重试就有可能导致有些消息重复发送了(当然导致消息重复也有可能是其他原因),那么怎么解决消息重复这个问题呢?
Kafka的生产者优秀架构设计
前言 Kafka 是一个高吞吐量的分布式的发布订阅消息系统,在全世界都很流行,在大数据项目里面使用尤其频繁。笔者看过多个大数据开源产品的源码,感觉 Kafka 的源码是其中质量比较上乘的一个,这得益于
一次 Docker 容器内大量僵尸进程排查分析
前段时间线上的一个使用 Google Puppeteer 生成图片的服务炸了,每个 docker 容器内都有几千个孤儿僵死进程没有回收,如下图所示。这篇文章比较长,主要就讲了下面这几个问题。- 什么情
What?一个 Dubbo 服务启动要两个小时!
前言前几天在测试环境碰到一个非常奇怪的与 ```dubbo``` 相关的问题,事后我在网上搜索了一圈并没有发现类似的帖子或文章,于是便有了这篇。希望对还未碰到或正在碰到的朋友有所帮助。 现象现象是这样
Jackson修改字段名和自定义命名策略
国庆期间写了一教程:[《轻松学习Jackson》程序员口袋里的开发手册](https://996geek.com/articles/164),这是其中的一篇。Jackson支持在处理数据的时候,使用不
又踩到Dubbo的坑,但是这次我笑不出来
前言直入主题,线上应用发现,偶发性出现如下异常日志。当然由于线上具体异常包含信息量过大,秉承让肥朝的粉丝没有难调试的代码的原则,我特意抽取了一个复现的demo放在了git,让你不在现场,一样享受到排查
Kafka 顺序消费线程模型的实践与优化
各类消息中间件对顺序消息实现的做法是将具有顺序性的一类消息发往相同的主题分区中,只需要将这类消息设置相同的 Key 即可,而 Kafka 会在任意时刻保证一个消费组同时只能有一个消费者监听消费,因此可