RocketMQ架构设计-以图示的方式梳理一下RocketMQ内部的层级关系

经过以上篇幅的介绍，我们已经很清晰的了解了在RocketMQ中，一条消息从生产到存储再到消费的整体过程，当然，这些是从微观细节上面探究的，在探究完了细节之后，我们从RocketMQ的整体架构设计上，看一下RocketMQ内部是如何组织代码结构的，层与层是如何划分的，这是本篇所描述的重点内容。

逻辑架构梳理

逻辑架构描述

网络接入层

RocketMQ的网络通信框架选用的Netty来实现的，BossGroup监听端口，监听到了新连接后注册到SelectorGroup中的一个EventLoop上，然后该EventLoop处理该连接上面的读写请求。

一般由Netty构建的网络服务通常由EventLoop线程进行编解码以及其他处理即可，但是RockeeMQ的Netty服务又扩展了一层线程池服务，将编解码以及其他的Handler处理交由EventExecutorGroup线程池来处理，这样做的目前就是为了避免EventLoop线程在其他事情上耽误时间，专心致志做自己的工作，提升了服务请求的接入能力。

业务逻辑处理层

在RocketMQ启动时会主动调用BrokerController这个类，这个类构建了RocketMQ的业务逻辑处理层，具有承上启下的作用。

向上承接新的业务逻辑请求，向下调用数据存储层提供的服务接口来执行数据的处理。自身也具有定时任务调度、Topic以及客户端相关信息维护的功能。

核心业务处理主要是一系列的Processor，例如:SendMessageProcessor、PullMessageProcessor等，这些处理器有自己对应的请求编码以及自身对应的线程池，客户端不同的请求编码对应的不同Processor，各自独立的线程池也进一步增强了自身的处理能力以及效率。

RocketMQ服务高可用的两个模式主从模式或者多副本协议模式也是在本层决定的。

存储逻辑处理层

这一层主要是从逻辑上面组织Commitlog、IndexFile、ConsumeQueue等相关数据的写入以及读取，为业务处理层开放相关数据操作接口。

主要的数据写入涉及Commitlog文件、IndexFile文件、ConsumeQueue文件，这三个文件在本层对应Commitlog、IndexFile、ConsumeQueue这三个主要的逻辑处理类，这三个逻辑处理类内部引用着存储处理层的MappedFile,并建立起了逻辑关联关系。

本层还涉及到了一些关于数据处理的定时任务以及数据持久化方面的处理方案。

存储处理层

RocketMQ关于数据方面的操作，本质上都是MappedFile来提供支持的。一个MappedFile的实例代表着一个本地磁盘的文件。逻辑处理层的几个主要类Commitlog、IndexFile、ConsumeQueue，也是内部关联着MappedFile，由MappedFile为他们提供数据方面的操作。

MappedFile中若使用transientStorePool，则数据先写入到堆外内存，再由堆外内存写入PageCache进而刷入磁盘，若没有使用transientStorePool，则数据直接写入PageCache，然后在刷入磁盘。数据读取的话，则是直接读取PageCache，若PageCache中没有则产生缺页中断，继而加载磁盘文件。

操作系统

利用操作系统提供的PageCache以及文件写入的相关接口，将数据写入到服务器的磁盘上。

利用操作系统提供的PageCache以及文件读取的相关接口，将磁盘数据读取到系统内存中。

本期回顾

本篇文件从整体上介绍了RocketMQ的层级关系，大概的梳理了一下RocketMQ的逻辑架构，方便读者从整体上理解RocketMQ，对于后期的源码研究也有一定的帮助。

以上内容可能存在疏漏或者不准确的地方，欢迎各位读者批评指正，共同进步，谢谢。

作者：一语长情

原文链接：https://juejin.cn/post/7154673831062274085