7张图揭晓RocketMQ存储设计的精髓

最新推荐文章于 2024-08-21 22:27:54 发布

2401_83915812

最新推荐文章于 2024-08-21 22:27:54 发布

阅读量601

点赞数 10

分类专栏：程序员文章标签： rocketmq 数据库

本文链接：https://blog.csdn.net/2401_83915812/article/details/137236718

版权

程序员专栏收录该内容

553 篇文章 2 订阅

订阅专栏

本文探讨了RocketMQ中Commitlog文件的设计以及ConsumeQueue的引入，以解决基于Topic的消息检索性能问题。同时介绍了内存映射、顺序写和刷盘策略对写入性能的影响，以及RocketMQ如何在性能和消息可靠性间取得平衡。

摘要由CSDN通过智能技术生成

00000000001073741824，然后依次类推。

这样做的好处是给出任意一个消息的物理偏移量，例如消息偏移量为 73741824，可以通过二分法进行查找，快速定位这个文件在第一个文件中，然后用消息的物理偏移量减去该文件的名称所得到的差值，就是在该文件中的绝对地址。

Commitlog 文件的设计理念是追求极致的消息写，但我们知道消息消费模型是基于主题的订阅机制，即一个消费组是消费特定主题的消息。如果根据主题从 commitlog 文件中检索消息，我们会发现这绝不是一个好主意，只能从文件的第一条消息逐条检索，其性能可想而知，故为了解决基于 topic 的消息检索问题，RocketMQ 引入了 consumequeue 文件，consumequeue 的结构如下图所示。

ConsumeQueue 文件是消息消费队列文件，是 Commitlog 文件基于 Topic 的索引文件，主要用于消费者根据 Topic 消费消息，其组织方式为/topic/queue，同一个队列中存在多个文件。

Consumequeue 的设计极具技巧，每个条目长度固定（8 字节 commitlog 物理偏移量、4 字节消息长度、8 字节 tag hashcode）。

这里不是存储 tag 的原始字符串，而选择存储 hashcode，目的就是确保每个条目的长度固定，可以使用访问类似数组下标的方式快速定位条目，极大地提高了 ConsumeQueue 文件的读取性能。

试想一下，消息消费者根据 topic、消息消费进度（consumeuqe 逻辑偏移量），即第几个 Consumeque 条目，这样的消费进度去访问消息的方法为使用逻辑偏移量 logicOffset * 20 即可找到该条目的起始偏移量（consumequeue 文件中的偏移量），然后读取该偏移量后 20 个字节即得到一个条目，无须遍历 consumequeue 文件。

RocketMQ 与 Kafka 相比具有一个强大的优势，就是支持按消息属性检索消息，引入 consumequeue 文件解决了基于 topic 查找的问题，但如果想基于消息的某一个属性查找消息，consumequeue 文件就无能为力了。

RocketMQ 引入了 Index 索引文件，实现基于文件的哈希索引。IndexFile 的文件存储结构如下图所示：

IndexFile 文件基于物理磁盘文件实现 Hash 索引。其文件由 40 字节的文件头、500万个 Hash 槽，每个 Hash 槽 4 个字节，最后由 2000万个 Index 条目，每个条目由 20个字节构成，分别为 4 字节索引 key 的 hashcode、8 字节消息物理偏移量、4 字节时间戳、4 字节的前一个 Index 条目（Hash 冲突的链表结构）。

即建立了索引 Key 的 hashcode 与物理偏移量的映射关系，根据 key 先快速定义到 commitlog 文件。

顺序写

===

基于磁盘的读写，提高其写入性能的另外一个设计原理是磁盘顺序写。

磁盘顺序写广泛用在基于文件的存储模型中，大家不妨思考一下 MySQL Redo 日志的引入目的，我们知道在 MySQL InnoDB 的存储引擎中，会有一个内存 Pool，用来缓存磁盘的文件块，当更新语句将数据修改后，会首先在内存中进行修改，然后将变更写入到 redo 文件(刷写到磁盘)，然后定时将 InnoDB 内存池中的数据刷写到磁盘。

为什么不一有数据变更，就直接更新到指定的数据文件中呢？以 MySQL InnoDB 中一个库存在上千张，每一个张的数据会使用单独的文件存储，如果每一个表的数据发生变更，就刷写到磁盘，就会存在大量的随机写入，性能无法得到提升，故引入一个 redo 文件，顺序写 redo 文件，从表面上多了一步刷盘操作，但由于是顺序写，相比随机写，带来的性能提升是非常显著的。

内存映射机制

======

虽然基于磁盘的顺序写可以极大提高 IO 的写效率，但如果基于文件的存储采用常规的 JAVA 文件操作 API，例如 FileOutputStream 等，其性能提升会很有限，RocketMQ 引入了内存映射，将磁盘文件映射到内存中，以操作内存的方式操作磁盘，性能又提升了一个档次。

在 JAVA 中可通过 FileChannel 的 map 方法创建内存映射文件。

在 Linux 服务器中由该方法创建的文件使用的就是操作系统的 pagecache，即页缓存。

Linux 操作系统中的内存使用策略时会尽可能地利用机器的物理内存，并常驻内存中，就是所谓的页缓存。在操作系统的内存不够的情况下，采用缓存置换算法，例如 LRU 将不常用的页缓存回收，即操作系统会自动管理这部分内存。

如果 RocketMQ Broker 进程异常退出，存储在页缓存中的数据并不会丢失，操作系统会定时将页缓存中的数据持久化到磁盘，做到数据安全可靠。不过如果是机器断电等异常情况，存储在页缓存中的数据就有可能丢失。

灵活多变的刷盘策略

=========

有了顺序写和内存映射的加持，RocketMQ 的写入性能得到了极大的保证，但凡事都有利弊，引入了内存映射和页缓存机制，消息会先写入到页缓存，此时消息并没有真正持久化到磁盘。那么 broker 收到客户端的消息发送后，是存储到页缓存中就直接返回成功，还是要持久化到磁盘中才返回成功呢？

这是一个“艰难”的抉择，是在性能与消息可靠性方面进行权衡。为此，RocketMQ 提供了多种策略：同步刷盘、异步刷盘。

1、同步刷盘

同步刷盘在 RocketMQ 的实现中成为组提交，并不是每一条消息都必须刷盘。其设计理念如图所示：

采用同步刷盘，每一个线程将数据追到到内存后，并向刷盘线程提交刷盘请求，然后会阻塞；刷盘线程从任务队列中获取一个任务，然后触发一次刷盘，但并不只刷与请求相关的消息，而是会直接将内存中待刷盘的所有消息一次批量刷盘，然后就可以唤醒一组请求线程，实现组刷盘。

2、异步刷盘

同步刷盘的优点是能保证消息不丢失，即向客户端返回成功就代表这条消息已被持久化到磁盘，即消息非常可靠，但这是以牺牲写入响应延迟性能为代价的，由于 RocketMQ 的消息是先写入 pagecache，故消息丢失的可能性较小，如果能容忍一定几率的消息丢失，可以考虑使用异步刷盘。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。