教育教学网站建设,做社情网站犯法怎么办,wordpress扫号器,wordpress统计查看简介#xff1a; RocketMQ 作为一款基于磁盘存储的中间件#xff0c;具有无限积压能力#xff0c;并提供高吞吐、低延迟的服务能力#xff0c;其最核心的部分必然是它优雅的存储设计。
存储概述
RocketMQ 存储的文件主要包括 Commitlog 文件、ConsumeQueue 文件、Index 文…简介 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 进程异常退出那么存储在堆外内存的数据会丢失但如果是放入 pagecachebroke r异常退出并不会丢失消息。
原文链接 本文为阿里云原创内容未经允许不得转载。
