RocketMQ入门

忘是亡心i 2023-02-20 02:22 118阅读 0赞

前言：公司要把ActiveMQ全部下架全换成RocetMQ了，正巧我负责的项目有部分用到了RocketMQ，所以来学习一下

参考：

[https://yq.aliyun.com/articles/66129?spm=5176.100240.searchblog.73.utoU93][https_yq.aliyun.com_articles_66129_spm_5176.100240.searchblog.73.utoU93]

[https://www.jianshu.com/p/824066d70da8][https_www.jianshu.com_p_824066d70da8]

[https://www.jianshu.com/p/2838890f3284][https_www.jianshu.com_p_2838890f3284]

[https://blog.csdn.net/qq\_34462387/article/details/86562856][https_blog.csdn.net_qq_34462387_article_details_86562856]

[https://blog.csdn.net/zhangcongyi420/article/details/90548393][https_blog.csdn.net_zhangcongyi420_article_details_90548393]

**目录**

第一章 RocketMQ由来

1.1 来源

第二章 RocketMQ原理

2.1 基本概念

2.2 运作原理

2.3 消息模型

2.3.1 广播消费

2.3.2 集群消费

2.3.3 pull和push

第三章 RocketMQ与ActiveMQ对比

第四章 RocketMQ的作用

4.1 异步处理

4.2 应用解耦

4.3 流量削峰

4.4 事务处理

--------------------

# 第一章 RocketMQ由来 #

## 1.1 来源 ##

阿里巴巴消息中间件起源于2001年的五彩石项目，Notify在这期间应运而生，用于交易核心消息的流转。

至2010年，B2B开始大规模使用ActiveMQ作为消息内核，随着阿里业务的快速发展，急需一款支持顺序消息，拥有海量消息堆积能力的消息中间件，MetaQ 1.0在2011年诞生。

到2012年，MetaQ已经发展到了MetaQ 3.0，并抽象出了通用的消息引擎RocketMQ。随后，将RocketMQ进行了开源，阿里的消息中间件正式走入了公众的视野。

到2015年，RocketMQ已经经历了多年双十一的洗礼，在可用性、可靠性以及稳定性等方面都有出色的表现。与此同时，云计算大行其道，阿里消息中间件基于RocketMQ推出了Aliware MQ 1.0，开始为阿里云上成千上万家企业提供消息服务。

到2016年，MetaQ在2016年双十一承载了万亿级消息的流转，跨越了一个新的里程碑，同时RocketMQ进入Apache 孵化。

![screenshot.png][]

#  第二章 RocketMQ原理 #

## 2.1 基本概念 ##

**Producer**：消息生产者，生产者的作用就是将消息发送到 MQ，生产者本身既可以产生消息，如读取文本信息等。也可以对外提供接口，由外部应用来调用接口，再由生产者将收到的消息发送到 MQ。

**Producer Group**：生产者组，简单来说就是多个发送同一类消息的生产者称之为一个生产者组。

**Consumer**：消息消费者，简单来说，消费 MQ 上的消息的应用程序就是消费者，至于消息是否进行逻辑处理，还是直接存储到数据库等取决于业务需要。

**Consumer Group**：消费者组，和生产者类似，消费同一类消息的多个 consumer 实例组成一个消费者组。

**Topic**：Topic 是一种消息的逻辑分类，比如说你有订单类的消息，也有库存类的消息，那么就需要进行分类，一个是订单 Topic 存放订单相关的消息，一个是库存 Topic 存储库存相关的消息。

**Message**：Message 是消息的载体。一个 Message 必须指定 topic，相当于寄信的地址。Message 还有一个可选的 tag 设置，以便消费端可以基于 tag 进行过滤消息。也可以添加额外的键值对，例如你需要一个业务 key 来查找 broker 上的消息，方便在开发过程中诊断问题。

**Tag**：标签可以被认为是对 Topic 进一步细化。一般在相同业务模块中通过引入标签来标记不同用途的消息。

**Broker**：Broker 是 RocketMQ 系统的主要角色，其实就是前面一直说的 MQ。Broker 接收来自生产者的消息，储存以及为消费者拉取消息的请求做好准备。

**Name Server**：Name Server 为 producer 和 consumer 提供路由信息。

## 2.2 运作原理 ##

注：

长与短连接：数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。

![format_png][]

1) Name Server

Name Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。

2) Broker

Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的Broker Name，不同的Broker Id来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。

每个Broker与Name Server集群中的所有节点建立长连接，定时(每隔30s)注册Topic信息到所有Name Server。Name Server定时(每隔10s)扫描所有存活broker的连接，如果Name Server超过2分钟没有收到心跳，则Name Server断开与Broker的连接。

3) Producer

Producer与Name Server集群中的其中一个节点(随机选择)建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。

Producer每隔30s（由ClientConfig的pollNameServerInterval）从Name server获取所有topic队列的最新情况，这意味着如果Broker不可用，Producer最多30s能够感知，在此期间内发往Broker的所有消息都会失败。

Producer每隔30s（由ClientConfig中heartbeatBrokerInterval决定）向所有关联的broker发送心跳，Broker每隔10s中扫描所有存活的连接，如果Broker在2分钟内没有收到心跳数据，则关闭与Producer的连接。

4) Consumer

Consumer与Name Server集群中的其中一个节点(随机选择)建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。

Consumer每隔30s从Name server获取topic的最新队列情况，这意味着Broker不可用时，Consumer最多最需要30s才能感知。

Consumer每隔30s（由ClientConfig中heartbeatBrokerInterval决定）向所有关联的broker发送心跳，Broker每隔10s扫描所有存活的连接，若某个连接2分钟内没有发送心跳数据，则关闭连接；并向该Consumer Group的所有Consumer发出通知，Group内的Consumer重新分配队列，然后继续消费。

当Consumer得到master宕机通知后，转向slave消费，slave不能保证master的消息100%都同步过来了，因此会有少量的消息丢失。但是一旦master恢复，未同步过去的消息会被最终消费掉。

总结：

Broker会定时注册topic到Name Server上，Producer与Consumer会定时从Name Server上读取Topic信息。

Name Server定时(每隔10s)扫描所有存活broker的连接，如果Name Server超过2分钟没有收到心跳，则Name Server断开与Broker的连接。

Broker每隔10s扫描所有存活的Producer连接，如果Broker在2分钟内没有收到心跳数据，则关闭与Producer的连接。

Broker每隔10s扫描所有存活的Consumer连接，若某个连接2分钟内没有发送心跳数据，则关闭连接；并向该Consumer Group的所有Consumer发出通知，Group内的Consumer重新分配队列，然后继续消费。

## 2.3 消息模型 ##

### 2.3.1 广播消费 ###

一条消息被多个 Consumer 消费，即使这些 Consumer 属于同一个 Consumer Group，消息也会被 Consumer Group 中的每个 Consumer 都消费一次，广播消费中的 Consumer Group 概念可以认为在消息划分方面无意义。

类似于ActiveMQ中的发布订阅模式

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3_size_16_color_FFFFFF_t_70][]

### 2.3.2 集群消费 ###

一个 Consumer Group 中的 Consumer 实例平均分摊消费消息。例如某个 Topic 有 9 条消息，其中一个 Consumer Group 有 3 个实例(可能是 3 个进程，或者 3 台机器)，那么每个实例只消费其中的 3 条消息。

类似于ActiveMQ中的虚拟主题模式

![20190120160452442.png][]

注：RocketMQ不遵循JMS规范，有一套自定义的机制，它不存在点对点和发布订阅模式的区别，简单的说，RMQ都是使用订阅主题的方式去发送和接收消息的，支持的消费模型有下面2种： 集群模式：消费端设置消费模式为MessageModel.CLUSTERING，这种方式就可以达到水平扩展负载均衡消费消息 广播模式：消费端设置消费模式MessageModel.BROADCASTING这种模式下，就是相当于生产者端发送消息到RMQ，多个消费者端可以同时获得消息消息，顾名思义广播模式

### 2.3.3 pull和push ###

在RocketMQ中一般有两种获取消息的方式，一个是拉(pull，消费者主动去broker拉取)，一个是推(push，主动推送给消费者)

**push：**

实时性高，但增加服务端负载，消费端能力不同，如果push的速度过快，消费端会出现很多问题

**pull：**

消费者从server端拉消息，主动权在消费端，可控性好，但是时间间隔不好设置，间隔太短，则空请求会多，浪费资源，间隔太长，则消息不能及时处理

**原理：**

push方式里，consumer把轮询过程封装了，并注册MessageListener监听器，取到消息后，唤醒MessageListener的consumeMessage()来消费，对用户而言，感觉消息是被推送过来的。

pull方式里，取消息的过程需要用户自己写，首先通过打算消费的Topic拿到MessageQueue的集合，遍历MessageQueue集合，然后针对每个MessageQueue批量取消息，一次取完后，记录该队列下一次要取的开始offset，直到取完了，再换另一个MessageQueue。

# 第三章 RocketMQ与ActiveMQ对比 #

因为之前只用过ActiveMQ所以就只和ActiveMQ对比一下了，貌似RocketMQ完全吊打ActiveMQ。。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70][]

# 第四章 RocketMQ的作用 #

## 4.1 异步处理 ##

以用户注册，并且需要注册邮件和短信为例。用户注册后，需要发送注册邮件和注册短信。传统的做法有两种：串行和并行方式。如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3_size_16_color_FFFFFF_t_70 1][]

引入消息队列后：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3_size_16_color_FFFFFF_t_70 2][]

## 4.2 应用解耦 ##

用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。如下图：

![20190120161841695.png][]

传统模式的缺点：

1）假如库存系统无法访问，则订单减库存将失败，从而导致订单失败。

2）订单系统与库存系统耦合

引入消息队列后：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3_size_16_color_FFFFFF_t_70 3][]

1）订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。

2）库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作。

假如：在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。

## 4.3 流量削峰 ##

流量削峰也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛。

秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，需要在应用前端加入消息队列。

1）可以控制活动的人数。

2）可以缓解短时间内高流量压垮应用。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3_size_16_color_FFFFFF_t_70 4][]

1）用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。

2）秒杀业务根据消息队列中的请求信息，再做后续处理。

## 4.4 事务处理 ##

注：这个还不大清楚，大概抄一下，回头去看一下数据库事务一致性和分布式系统数据、分布式事务消息一致性再来详细说一下，参考：[https://www.jianshu.com/p/2838890f3284][https_www.jianshu.com_p_2838890f3284]。

比如银行转账。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3_size_16_color_FFFFFF_t_70 5][]

如果确认消息发送失败了怎么办？RocketMQ会定期扫描消息集群中的事物消息，如果发现了Prepared消息，它会向消息发送端(生产者)确认，钱到底是减了还是没减呢？如果减了是回滚还是继续发送确认消息呢？RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败 。

[https_yq.aliyun.com_articles_66129_spm_5176.100240.searchblog.73.utoU93]: https://yq.aliyun.com/articles/66129?spm=5176.100240.searchblog.73.utoU93
[https_www.jianshu.com_p_824066d70da8]: https://www.jianshu.com/p/824066d70da8
[https_www.jianshu.com_p_2838890f3284]: https://www.jianshu.com/p/2838890f3284
[https_blog.csdn.net_qq_34462387_article_details_86562856]: https://blog.csdn.net/qq_34462387/article/details/86562856
[https_blog.csdn.net_zhangcongyi420_article_details_90548393]: https://blog.csdn.net/zhangcongyi420/article/details/90548393
[screenshot.png]: https://imgconvert.csdnimg.cn/aHR0cDovL2F0YTItaW1nLmNuLWhhbmd6aG91LmltZy1wdWIuYWxpeXVuLWluYy5jb20vOGY3MDlmMzRhZjNiZWVlMWYxZmVkM2E3NGU5ZDYwOTAucG5n?x-oss-process=image/format,png
[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMjYxOTE1OS1hODU4ZDM4ZTBiMzhjNDA2LnBuZw?x-oss-process=image/format,png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20190120160528325.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3,size_16,color_FFFFFF,t_70
[20190120160452442.png]: https://img-blog.csdnimg.cn/20190120160452442.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200622045330486.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20190120161447848.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20190120161712475.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3,size_16,color_FFFFFF,t_70
[20190120161841695.png]: https://img-blog.csdnimg.cn/20190120161841695.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20190120161958924.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20190120162153375.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20190120162635963.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NDYyMzg3,size_16,color_FFFFFF,t_70