超详细的RocketMq知识点讲解以及实战

最新推荐文章于 2025-03-19 21:54:23 发布

魔笑

最新推荐文章于 2025-03-19 21:54:23 发布

阅读量3.8k

点赞数 20

分类专栏：学习和分享 RocketMq 文章标签： java

本文链接：https://blog.csdn.net/weixin_44291453/article/details/119852614

版权

大家好我是魔笑，下面是对RocketMq知识点的一些讲解，以及代码实战，如果有讲的不对的地方，请多指教。，前期介绍了，RockeMq部署架构，以及角色以及相关术语进行讲解。后面主干是从上产消息，存储消息，消费消息，消息流控这条线去梳理知识点的，希望能对你学习RockeMq能更好的理解。

如果想知道lunix怎么安装RocketMq，请看这篇文章：
https://blog.csdn.net/weixin_44291453/article/details/119494263

二，Rocketmq的应用场景

三，RocketMq的部署架构

四，RocketMq的模型

五，RocketMq生产消息重要的知识点以及实战

六，RocketMQ存储消息

七，RocketMQ消费消息重要知识点以及实战

八，高可用和负载均衡

九，Sentinel对RocketMQ进行限流实战

一，什么是Rocketmq？

rocketmq是阿里借鉴kafaka改造和优化而来的,用的是java语言写的。支持了阿里历年的双十一，系统的稳定性是很可靠的。

二，Rocketmq的应用场景

*应用解耦

可以解耦出一些系统，用RocketMq进行解耦，例如将订单发到RocketMQ中，然后订单系统对其消费

*流量削峰

如果系统有大量的请求过来，很可能导致系统奔溃，我们可以将消息发到RocketMQ中进行消息缓存，然后分散处理

*数据分发

我们可以将信息发到rocketMq中，由下游系统去选择性的消费

三，RocketMq的部署架构

从服务的角色分

Producer：消息的生产者，Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer获取Topic路由信息，并向提供Topic 服务的Master建立长连接，且定时向
Master发送心跳。

Consumer：消息的消费者，Consumer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer获取Topic路由信息,并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳

Broker：暂存和传输消息，Topic就是存放在Broker中的，可搭建主从架构，一个Master和多个slaver

Nameserver：管理Broker，Broker的元数据都要注册给NameServer。每次消费者或者生产者从nameServer获取到Broker的元数据（包括Broker的ip和端口，和所有Topic信息），Nameserver可集群部署，节点之间无任何信息同步

Topic：区分消息的种类；一个发送者可以发送消息给一个或者多个Topic；一个消息的接收者
可以订阅一个或者多个Topic消息

Message Queue：相当于是Topic的分区；用于并行发送和接收消息

注，一个Topic默认有四个Message Queue

1)消息模型（Message Model）
RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，
Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。MessageQueue 用于存储消息的物理地址，每个Topic中的消息地址存储于多个 Message Queue 中。ConsumerGroup 由多个Consumer 实例构成。ProducerGroup(生产组)由多个Producer组成

producerGroup:同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致

        //生产组为producer_01
        DefaultMQProducer producer = new DefaultMQProducer("producer_01");

ConsumerGroup:同一类Consumer的集合，这类Consumer通常消费同一类消息且消费逻辑一至，消费者组的消费者实例必须订阅完全相同的Topic

            //消费组为consumer_01,
            DefaultMQPullConsumer consumer = new DefaultMQPullConsumer("consumer_01");

五，RocketMq生产消息重要的知识点以及实战

首先介绍消息的发送

生产者向消息队列里写入消息，不同的业务场景需要生产者采用不同的写入策略。比如同步发送、
异步发送、Oneway发送、延迟发送、发送事务消息等。默认使用的是DefaultMQProducer类。

什么是同步发送？什么是异步发送？我们先看看下面的两个知识点，同步方式和刷盘机制

1，当Broker是主从架构时，master和slave同步方式

同步复制和异步复制的设置：在/conf/broker.conf，中设置参数brokerRole，默认是ASYNC_MASTER（异步复制），可设置为SYNC_MASTER（同步复制）

当我们在发消息时，如果是异步发送，那么我们将消息发送给broker,我们就返回状态，broker再去异步的刷盘和同步给slave，如果Broker挂了，这样容易导致信息丢失。

如果我们是同步发送，那么我们将信息发送给broker,等broker刷盘，并且同步给slave后我们再返回成功，一般不会发生消息丢失。

2，Broker的刷盘机制：

同步刷盘和异步刷盘的设置：在/conf/broker.conf ，中设置参数flushDiskType，默认的是ASYNC_FLUSH（异步刷盘），可设置为SYNC_FLUSH（同步刷盘）

同步刷盘：当生产者在将消息发到Broker时，会等待消息刷盘后才返回成功

异步刷盘：当生产者将消息发到Broker时，不会等待消息刷盘就返回状态

同步刷盘流程发：

(1). 写入 PageCache后，线程等待，通知刷盘线程刷盘。
(2). 刷盘线程刷盘后，唤醒前端等待线程，可能是一批线程。
(3). 前端等待线程向用户返回成功

同步刷盘和异步刷盘区别：同步刷盘与异步刷盘的唯一区别是异步刷盘写完 PageCache直接返回，而同步刷盘需要等待刷盘完成才返回

理解了上面的两个知识点接下来看看，我们发送消息都有哪些状态

FLUSH_DISK_TIMEOUT：表示没有在规定时间内完成刷盘（需要Broker的刷盘策略被设置成SYNC_FLUSH才会报这个错误）。
FLUSH_SLAVE_TIMEOUT：表示在主备方式下，并且Broker被设置成SYNC_MASTER（同步复制）方式，没有在设定时间内完成主从同步。
SLAVE_NOT_AVAILABLE：这个状态产生的场景和FLUSH_SLAVE_TIMEOUT类似，表示在主备方式下，并且Broker被设置成SYNC_MASTER（同步复制），但是没有找到被配置成Slave的Broker。
SEND_OK：表示发送成功，发送成功的具体含义，比如消息是否已经被存储到磁盘？消息是

否被同步到了Slave上？消息在Slave上是否被写入磁盘？需要结合所配置的刷盘策略、主从策
略来定。这个状态还可以简单理解为，没有发生上面列出的三个问题状态就是SEND_OK。

从上面我们就可以知道我们发送消息，然后根据返回结果，就可以对应的处理了。那么也就解释了什么是同步消息，异步消息了，接下来我们说说其他几种消息

3，定时消息：

定时消息（延迟队列）是指消息发送到broker后，不会立即被消费，等待特定时间投递给真正的
topic。

broker有配置项messageDelayLevel，默认值为“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m
9m 10m 20m 30m 1h 2h”，18个level。

level == 0，消息为非延迟消息
1<=level<=maxLevel，消息延迟特定时间，例如level==1，延迟1s
level > maxLevel，则level== maxLevel，例如level==20，延迟2h

原理：定时消息会暂存在名为SCHEDULE_TOPIC_XXXX的topic中，并根据delayTimeLevel存入特定的queue，即一个queue只存相同延迟的消息，这16个级别，也就有16个queue，保证具有相同发送延迟的消息能够顺序消费，当时间到了，broker会调度地消费SCHEDULE_TOPIC_XXXX，将消息写入真实的topic

在java代码中设置定时的是：

Message message=new Message("tp-1","*",("hell word").getBytes());
message.setDelayTimeLevel(i);

4，事务消息：

RocketMQ事务消息（Transactional Message）是指应用本地事务和发送消息操作可以被定义到
全局事务中，要么同时成功，要么同时失败。RocketMQ的事务消息提供类似 X/Open XA 的分布事务功能，通过事务消息能达到分布式事务的最终一致性。

RocketMQ事务消息是二阶段提交方式实现事务消息的。我们用一个例子说明一下流程，比如银行转账，A银行的某账户要转一万元到B银行的某账户。A银行发送“B银行账户增加一万元”这个消息，要和“从A银行账户扣除一万元”这个操作同时成功或者同时失败

流程如下
1）发送待确认信息（B银行账户增加一万元）到RocketMq。

2）RocketMq收到信息将信息持久化，向发送方回复消息已经发送成功。

3）发送方执行本地事务（A银行减一万元），

4）发送方根据本地事件执行结果向RocketMq发送二次确认（Commit或是Rollback）信息，RocketMQ收到Commit状态则将第一阶段消息标记为可投递，订阅方将能够收到消息，收到
Rollback状态则删除第一阶段的消息，订阅方接收不到该消息。

5）如果出现异常情况，步骤4）提交的二次确认最终未到达RocketMQ，服务器在经过固定时间段
后将对“待确认”消息发起回查请求。

6）如果发送一阶段消息的Producer不能工作，就访问同生产组的其他produrce，通过检查对应消息的本地事件执行结果返回Commit或Roolback状态。

7）RocketMQ收到回查请求后，按照步骤4）的逻辑处理。

下面是RocketMq流程图：

1,MQ Producer发送Send HalfMsg到MQ Server

2,MQ Server持久化信息，返回 Half msg Send OK

3,执行本地事务，Local Transaction

4,本地事务执行完，返回4 commit or RollBack MQserver根据返回结果，commit Send Msg 或者 Rollback Delete msg

5，如果本地事务没有返回结果，MQ Server 执行Check Back

6,检查本地事务（Check the state of Local）

7,根据检查本地事务，返回Commit或者Rollback

下面是执行事务的实现类：

第一个类是LocalTransaction-Executer，用来实例化步骤3）的逻辑，根据情况返回LocalTransactionState.ROLLBACK_MESSAGE或者LocalTransactionState.COMMIT_MESSAGE状态。

第二个类是TransactionMQProducer，它的用法和DefaultMQProducer类似，要通过它启动一个Producer并发消息，但是比DefaultMQProducer多设置本地事务处理函数和回查状态函数。

第三个类是TransactionCheckListener，实现步骤5）中MQ服务器的回查请求，返回LocalTransactionState.ROLLBACK_MESSAGE或者LocalTransac

最低0.47元/天解锁文章