简介：RocketMQ 作为一款基于磁盘存储的中间件，具备有限积压能力，并提供高吞吐、低提早的服务能力，其最外围的局部必然是它优雅的存储设计。

RocketMQ 作为一款基于磁盘存储的中间件，具备有限积压能力，并提供高吞吐、低提早的服务能力，其最外围的局部必然是它优雅的存储设计。

存储概述

RocketMQ 存储的文件次要包含 Commitlog 文件、ConsumeQueue 文件、Index 文件。

RocketMQ 将所有主题的音讯存储在同一个文件中，确保音讯发送时按程序写文件，尽最大能力确保音讯发送的高可用性与高吞吐量。

但消息中间件个别都是基于主题的订阅与公布模式，音讯生产时必须依照主题进行帅选音讯，显然从 Commitlog 文件中依照 topic 去筛选音讯会变得及其低效，为了进步依据主题检索音讯的效率，RocketMQ 引入了 ConsumeQueue 文件，俗成生产队列文件。

关系型数据库能够依照字段属性进行记录检索，作为一款次要面向业务开发的消息中间件，RocketMQ 也提供了基于音讯属性的检索能力，底层的外围设计理念是为 Commitlog 文件建设哈希索引，并存储在 Index 文件中。

在 RocketMQ 中程序写入到 Commitlog 文件后，ConsumeQueue 与 Index 文件都是异步构建的，其数据流向图如下：

存储文件组织形式

RocketMQ 在音讯写入过程中谋求极致的磁盘程序写。所有主题的音讯全副写入一个文件，即 Commitlog 文件。所有音讯按到达程序顺次追加到文件中，音讯一旦写入，不反对批改。Commitlog 文件的具体布局如下图所示：

基于文件编程与基于内存编程有一个很大的不同是在基于内存的编程模式中咱们有现成的数据结构，例如 List、HashMap，对数据的读写十分不便，那么一条一条音讯存入文件 Commitlog 后，该如何查找呢？

正如关系型数据会为每一条数据引入一个 ID 字段，在基于文件编程的模型中，也会为一条音讯引入一个身份标记：音讯物理偏移量，即音讯存储在文件的起始地位。

正是有了物理偏移量的概念，Commitlog 的文件名命名也是极具技巧性，应用了存储在该文件的第一条音讯在整个 Commitlog 文件组中的偏移量来命名，例如第一个  Commitlog 文件为 

0000000000000000000，第二个文件为

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，故音讯失落的可能性较小，如果能容忍肯定几率的音讯失落，能够思考应用异步刷盘。

异步刷盘指的是 broker 将音讯存储到 pagecache 后就立刻返回胜利，而后开启一个异步线程定时执行 FileChannel 的 forece 办法，将内存中的数据定时刷写到磁盘，默认距离为 500ms。

内存级读写拆散

RocketMQ 为了升高 pagecache 的应用压力引入了 transientStorePoolEnable 机制，即内存级别的读写拆散机制。

默认状况下 RocketMQ 将音讯写入 pagecache，音讯生产时从 pagecache 中读取，这样在高并发时 pagecache 的压力会比拟大，容易呈现刹时 broker busy，故 RocketMQ 还引入了 transientStorePoolEnable，将音讯先写入堆外内存并立刻返回，而后异步将堆外内存中的数据提交到 pagecache，再异步刷盘到磁盘中。其工作机制如下图所示：

音讯在生产读取时不会尝试从堆外内存中读，而是从 pagecache 中读取，这样就造成了内存级别的读写拆散，即音讯写入时次要面对堆外内存，而读音讯时次要面对 pagecache。

该计划的长处是音讯是间接写入堆外内存，而后异步写入 pagecache。相比每条音讯追加间接写入 pagechae，其最大的劣势是将音讯写入 pagecache 操作批量化。

该计划的毛病是如果因为某些意外操作导致 Broker 过程异样退出，那么存储在堆外内存的数据会失落，但如果是放入 pagecache，broke r 异样退出并不会失落音讯。

版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。