RocketMQ架构原理解析（一）：整体架构

一、概述

RocketMQ作为一个apache的顶级项目，拥有将近16K的star，它稳定的系统及强悍的性能，无疑在国内已经成为了企业消息队列的首选。接下来的一段时间，鄙人准备出一系列文章，从源码出发，逐一剖析RocketMQ的架构设计原理

本文将仅做概念上的陈述

github地址

二、概念及模型

本文中部分概念描述搬运自github官网

RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。其他概念随着行文逐一展开。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图片搬运自官网

2.1 消息生产者（Producer）

负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。

2.2 消息消费者（Consumer）

负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。

2.3 服务器（Broker Server）

消息中转角色，负责存储消息、转发消息。代理服务器在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。代理服务器也存储消息相关的元数据，包括消费者组、消费进度偏移和主题和队列消息等。

2.3 主题（Topic）

表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。

三、部署架构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图片搬运自官网

RocketMQ各模块启动顺序如下：

1. 控制中心 启动NameServer，NameServer起来后监听端口，等待Broker、Producer、Consumer连上来，相当于一个路由控制中心
2. 服务端 Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系
3. 必要环节 收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic
4. 客户端1-生产消息 Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息
5. 客户端2-消费消息 Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息

四、消息存储

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

后文会逐一展开