RocketMQ的学习历程(5)----broker内部设计

文章目录

    • 概要
    • 整体架构流程
    • 技术名词解释
      • CommitLog和ConsumeQueue
      • 页缓存和内存映射
      • 刷盘机制
    • 小结

概要

在首个学习历程中,我们已经了解了,RokctMQ简单的工作流程。

如果想要更深的理解RokcetMQ消息处理的流程,broker内部流程的理解是必要的,
这里我们就了解一下Broker内部的工作流程。

整体架构流程

RocketMQ的学习历程(5)----broker内部设计_第1张图片

当Consumer消费消息时,需要先读取ConsumeQueue得到offset,再通过offset找到CommitLog对应的消息内容。

技术名词解释

CommitLog和ConsumeQueue

  • CommitLog:CommitLog是RocketMQ中消息主体以及元数据的存储主体,存储Producer端写入的消息主体内容,消息内容不是定长的。
    1. 在RocketMQ中,所有topic的消息都存储在一个称为CommitLog的文件中,该文件默认最大为1GB,超过1GB后会轮到下一个CommitLog文件。

    2. CommitLog文件存储在${ROCKET_HOME}/store/commitlog目录下。

    3. 顺序写入,随机读写。

    4. 消息只要被写入 commitlog 那么该消息就不会丢失

    5. 消息是非定长的

    6. 文件的命名是以 commitlog 起始偏移量命名的

  • ConsumeQueue:消息消费队列引入的目的主要是提高消息消费的性能。
    1. 由于RocketMQ是基于主题topic的订阅模式,消息消费是针对主题进行的,如果要遍历comitlag文件中根据topic检索消息是非常低效的。
    2. Consumer即可根据ConsumeQueue来查找待消费的消息。其ConsumeQueue(逻辑消费队列)作为消费消息的索引,保存了指定Topic下的队列消息在CommiL og中的起始物理偏移量ofiset,消息大小size和消息JTag的HashCode值。consumequeue文件可以看成是基于topic的commitlog索引文件
    3. 故consumequeue文件夹的组织方式如下: topic/queue/file三层组织结构,具体存储路为:$HOMEistorelconsumequeve(topiclqLeuel)ifieName)。
    4. 同样consumequecue文件采取定长设计,每一个条目共20个字节,分别为8字节的comitlog物理偏移量、4字节的消息长度、8字节tag hashcode,单个文件由30W个条目组成,可以像数组一样随机访问每一个条目,每个ConsumeQueue文件大小约5.72M;

页缓存和内存映射

  • 页缓存和内存映射页缓存(PageCache)是OS对文件的缓存,用于加速对文件的读写,内存映射是指将文件映射到进程的地址空间,使得应用程序可以像访问内存一样访问文件
    1. RocketMQ使用了内存映射文件的办法,将一个文件映射到进程的地址空间,实现文件的磁盘地址和进程的一段虚拟地址关联,实际上是利用了NIO 中的 FileChannel 模型。RocketMQ通过使用内存映射文件来提高IO访问性能,无论是CommitLog、 ConsumeQueue还是IndexFile,单个文件都被设计为固定长度,如果一个文件写满以后再创建一个新文件,文件名就为该文件第一条消息对应的全局物理偏移量。

    2. RocketMQ中的页缓存和内存映射都是文件系统中的缓存机制。RocketMQ单独创建一个MappedByteBuffer内存缓存池,用来临时存储数据,数据先写入该内存映射中,然后由commit线程定时将数据从该内存复制到与目的物理文件对应的内存映射中。

刷盘机制

RocketMQ提供了同步和异步两种刷盘方式
RocketMQ的学习历程(5)----broker内部设计_第2张图片

  1. 同步刷盘方式能够保证数据被写入硬盘,做到真正的持久化,但是也会让系统的写入速度受制于磁盘的IO速度;
  2. 而异步刷盘方式在将数据写入缓冲之后就返回,提供了系统的IO速度,却存在系统发生故障时未来得及写入硬盘的数据丢失的风险。

小结

本节我们简单了解了broker内部的简单流程知识,期待一起进步。

你可能感兴趣的:(分布式,RocketMQ,web的学习历程,java-rocketmq,rocketmq,学习)