money9sun的博客

消息消费队文件、消息属性索引文件都是基于CommitLog文件构建的，当消息生产者提交的消息存储在CommitLog文件中，ConsumerQueue、indexFile需要及时更新，否则消息无法及时被消费，根据消息属性查找消息也会出现较大延迟。RocketMQ通过开启一个线程ReputMessageservice来准实时转发Commitlog文件更新事件，相应的任务处理器根据转发的消息及时更新ConsumerQueue、indexFile文件。

我们针对源码来看下消息存储的流程，这里主要说明内存写入的过程，刷盘的机制在后面再讲。

RocketMQ通过使用内存映射文件提高!0访问性能，无论是CommitLog、ConsumerQueue还是IndexFile，单个文件都被设计为固定长度，如果一个文件写满以后再创建一个新文件，文件名就为该文件第一条消息对应的全局物理偏移量。我们看下一个commitLog文件大小是1GB一个comsumerQueue文件大小是5.72MB一个indexFile文件大小是 400MB。

消息发送的过程可以分成四步，分别是验证消息、查找路由、选择队列、发送消息验证消息：检查msg、检查topic、检查body；查找路由：先查本地缓存，如果为空从namesrv中获取并更新；选择队列：使用index+1再取模的方式进行负载均衡选择队列；发送消息：最终通过NettyRemotingClient发送请求。

生产者服务核心接口和类的关系如下图所示：MQProducer是生产者解耦，这里找几个有代表性的方法// 同步发送消息// 同步超时发送消息 如果超过了timeout的时间就抛出异常//异步发送消息// 异步超时发送消息 如果超过了timeout的时间就抛出异常// 指定消息队列同步发送消息。

Nameserver的主要作用是为消息的生产者和消息消费者提供关于主题Topic的路由信息，那么Nameserver需要存储路由的基础信息，还要管理Broker节点，包括路由注册、路由删除等。

首先来看一章总体的技术架构图消息中间件的设计思路一般是基于主题订阅发布的机制，消息生产者(Producer)发送某一个主题到消息服务器，消息服务器负责将消息持久化存储，消息消费者(Consumer)订阅该兴趣的主题，消息服务器根据订阅信息(路由信息)将消息推送到消费者(Push模式)或者消费者主动向消息服务器拉去(Pu模式)，从而实现消息生产者与消息消费者解耦。为了避免消息服务器的单点故障导致的整个系统瘫痪，通常会部署多台消息服务器共同承担消息的存储。那消息生产者如何知道消息要发送到哪台消息服务器呢?

从本章开始我们对Rocketmq的源码进行解析。使用版本是4.9.8。