RocketMQ 源码分析-概述

什么是 RocketMQ

RocketMQ 是一个基于主题的发布与订阅模式的消息队列中间价。其设计核心追求高性能、高吞吐量、高可用。 MQ 的核心功能就是消息的接受、发送、存储消息。

基本架构

其基本架构由客户端（包括消息的生产者和消费者），NameSrv，Broker 组成。

NameSrv 像是“注册中心/服务发现”，但实际上只是简单的路由信息的管理模块，其高可用通过部署多个 NameSrv 来保证，各个 NameSrv 之间不进行通信，允许分钟级的数据不一致。

Broker 则是定期上报各种路由信息给 NameSrv，并且复制接收、推送/拉取消息以及消息持久化。比如收到消息后先写入缓冲区，之后以同步/异步的方式刷盘写入 commit.log，并且异步转发给 ConsumeQueue 或者 index 文件方便以 topic 或者索引的方式检索消息等等。

客户端从 NameSrv 上同步路由信息，并在本地进行缓存，然后根据路由信息找到对应的 Broker 进行消息的发布和订阅。

大致流程

1. Producer 向 Broker 发送消息：

   从使用者的角度去看，Producer 是向 Topic 发布消息；从数据流动角度看，是从 Producer 流动到 Broker。

   先根据 topic 检查本地路由表（Producer 每 30s 会从 NameServer 拉一次），本地没有就带着 topic 去 NameServer 查询，查到了就按具体情况选好 Broker 发送消息；如果没查到（假设没有开启自动创建主题机制）抛出路由信息错误。最后 Producer 是否接收返回信息以及用什么方式处理返回信息取决于采取的是哪种发送方式。

   自动创建主题机制就是如果启用了该机制， Broker 会自动创建一个 TOPIC（名字挺奇怪的叫 "TBW102"，难道是淘宝网102？）以及对应的路由信息，所有错误/不存在的 topic 的路由信息都存在这里，TBW102 的路由信息也会自动上报到 NameServer。

   换句话说，当你写错 topic 的时候，Producer 执行 topic 路由的过程就变成了使用 "TBW102" 这个 topic 进行路由的过程。

2. Broker 存储消息

   Broker 收到消息后，把消息写入 commit.log 文件，同时还有一个线程不断从 commit.log 中读取消息数据转发给消费队列。

3. Consumer 消费消息

   Consumer 与 Broker 之间传递消息有两种方式:pull & push。其他的什么消费组，各种模式等等细节后续章节展开。

   RocketMQ 中，Consumer 消费消息是基于消费组 ConsumerGroup 开展的，一个消费组可以包含多个消费者，消费组可以订阅多个 Topic。

   消费组 ConsumerGroup 由 Consumer 组成，在不同的消费模式，消费组的行为并不一致。

   为了满足不同使用场景，RocketMQ 提供了两种消费模式：集群模式、广播模式。

   集群模式就是把消费组内的所有 Consumer 视为一个集群，同一个 Topic 下的同一条消息只能被其中一个 Consumer 消费，换句话说就是一条消息只能被集群（也就是 ConsumerGroup）消费一次。

   广播模式则是把消费组内的 Consumer 视为不同个体，一条消息可以被所有 Consumer 消费。

   Consumer 获取消息有两种模式: pull & push。

   拉模式： Consumer 主动向 Broker 发送拉取消息的请求。

   推模式： Broker 主动向 Consumer 推送消息，但实际上 Broker 不会向 Consumer 推送消息，推模式依然是 Consumer 自己去 pull，这里推拉两种模式主要是从使用角度，后续中展开细说。

前置要求

阅读官方文档，完成 RocketMQ 的本地部署，并尝试发送和消费消息。下一节将从发送消息入手进行源码分析。