RocketMQ核心技术精讲-----初识RocketMQ与快速上手

特此注明 ：
Designed By ：长安城没有风
Version：1.0
Time：2025.10.24
Location：辽宁 · 大连

📕1. 初识RocketMQ

RocketMQ 是阿里巴巴开源的一款分布式消息中间件，最初是为了解决“双十一”这种极端高并发下的电商场景而设计的。它后来被捐赠给 Apache 基金会，成为 Apache RocketMQ。简单说，它是一个高性能、低延迟、可扩展的消息队列系统，用来在不同系统或服务之间异步传递消息。Rocket的中文意思是火箭，MQ是Message Queue的缩写。

✏️1.1 RocketMQ 的核心作用

1. 应用解耦

系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。

使用消息队列解耦合，系统的耦合性就会提高了。比如物流系统发生故障，需要几分钟才能来修复，在这段时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作正常完成。当物流系统回复后，补充处理存在消息队列中的订单消息即可，终端系统感知不到物流系统发生过几分钟故障。

2. 流量削峰

应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮。有了消息队列可以将大量请求缓存起来，分散到很长一段时间处理，这样可以大大提到系统的稳定性和用户体验。

在实际业务中，为了保证系统稳定性，当系统负载超过设定阈值时，通常会直接拒绝用户请求，以防止系统崩溃。但这样做势必会影响用户体验。

如果引入消息队列，可以将高峰期的请求暂存起来，等系统有空闲资源时再进行处理，并在处理完成后通知用户下单成功。这样一来，即使在高并发场景下，也能保证系统稳定运行，同时平衡性能与体验。

从经济角度考虑，业务系统在正常时段的 QPS 约为 1000，而峰值可能达到 10000。为了应对这种短暂的流量高峰而长期维持高性能服务器显然成本过高。此时使用消息队列进行“削峰填谷”，能有效平滑流量、降低资源成本并提升系统整体的可用性。

3. 数据分发

以电商系统为例：用户在A系统下完单之后需要调用D系统进行付款，可是当我们想让用户先使用优惠卷然后再付款，就意味着需要在A系统中删除调用D系统的代码，新增调用E系统（优惠卷系统）的代码，频繁修改代码对于代码维护非常不方便。

通过消息队列可以让数据在多个系统更加之间进行流通。数据的产生方不需要关心谁来使用数据，只需要将数据发送到消息队列，数据使用方直接在消息队列中直接获取数据即可。

✏️1.2 RocketMQ 的优点和缺点

优点 ：

1. 解耦
2. 削峰
3. 数据分发

缺点：

1. 系统可用性降低。系统引入的外部依赖越多，系统稳定性越差。一旦MQ宕机，就会对业务造成影响。那么如何保证MQ的高可用呢？
2. 系统复杂度提高。MQ的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过MQ进行异步调用。如何保证消息没有被重复消费？怎么处理消息丢失情况？那么保证消息传递的顺序性？
3. 一致性问题。A系统处理完业务，通过MQ给B、C、D三个系统发消息数据，如果B系统、C系统处理成功，D系统处理失败。如何保证消息数据处理的一致性？

🧑‍🚀对于上述所提到的问题也是后续我们会重点讨论的内容。

✏️1.3 各种 MQ 产品的比较

常见的MQ产品包括Kafka、ActiveMQ、RabbitMQ、RocketMQ。

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
开发语言	Java	Erlang	Java	Scala
单机吞吐量	万级	万级	十万级	十万级
时效性	ms级	us级	ms级	ms级以内
可用性	高（主从架构）	高（主从架构）	非常高（分布式架构）	非常高（分布式架构）

📕2. RocketMQ 快速入门

下面介绍在Ubuntu系统手动安装RocketMQ服务（5.3.0）

✏️2.1 下载 RocketMQ

去 Apache 官方镜像站（建议用最新稳定版）,RocketMQ需要jdk环境支持，安装之前先安装jdk。

wget https://archive.apache.org/dist/rocketmq/5.3.0/rocketmq-all-5.3.0-bin-release.zip

✏️2.2 解压

sudo apt install unzip -y
unzip rocketmq-all-5.3.0-bin-release.zip
cd rocketmq-all-5.3.0-bin-release

✏️2.3 启动NameServer服务

启动之前一定要修改配置文件中的内存配置，否则会启动失败。

nohup sh bin/mqnamesrv &# 查看是否启动成功
ps -ef | grep mqnamesrv# 修改NameServer服务配置文件
vim bin/runserver.sh

✏️2.4 启动Broker服务

# 启动并在注册中心注册
nohup sh bin/mqbroker -n localhost:9876 &

✏️2.5 测试Producer服务

# 1.设置环境变量，将生产者服务在注册中心注册
export NAMESRV_ADDR=localhost:9876
# 2.使用安装包的Demo发送消息
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer

✏️2.6 测试Consumer服务

# 1.设置环境变量，将消费者服务在注册中心注册
export NAMESRV_ADDR=localhost:9876
# 2.接收消息
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer

✏️2.7 关闭服务

📕3. RocketMQ 集群

✏️3.1 角色介绍

1. Producer：消息的发送者；举例：发信者
2. Consumer：消息接收者；举例：收信者
3. Broker：暂存和传输消息；举例：邮局
4. NameServer：管理Broker；举例：各个邮局的管理机构
5. Topic：区分消息的种类；一个发送者可以发送消息给一个或者多个Topic；一个消息的接收者可以订阅一个或者多个Topic消息
6. Message Queue：相当于是Topic的分区；用于并行发送和接收消息
   

✏️3.2 集群特点

1. NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
2. Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。
3. Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
4. Consumer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。

✏️3.3 集群模式

单Master模式：这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用。不建议线上环境使用,可以用于本地测试。

多Master模式：一个集群无Slave，全是Master，例如2个Master或者3个Master，这种模式的优缺点如下：

1. 优点：配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高；
2. 缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。

多Master多Slave模式（异步）：每个Master配置一个Slave，有多对Master-Slave，HA采用异步复制方式，主备有短暂消息延迟（毫秒级），这种模式的优缺点如下：

1. 优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，同时Master宕机后，消费者仍然可以从Slave消费，而且此过程对应用透明，不需要人工干预，性能同多Master模式几乎一样；
2. 缺点：Master宕机，磁盘损坏情况下会丢失少量消息。

多Master多Slave模式（同步）：每个Master配置一个Slave，有多对Master-Slave，HA采用同步双写方式，即只有主备都写成功，才向应用返回成功，这种模式的优缺点如下：

1. 优点：数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；
2. 缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。