RocketMQ-了解认识MQ

程序员路同学

已于 2022-07-12 15:15:12 修改

阅读量329

点赞数

CC 4.0 BY-SA版权

分类专栏： RocketMQ 文章标签：消息队列

于 2021-06-18 18:55:59 首次发布

鹿少年

本文链接：https://blog.youkuaiyun.com/huanglu0314/article/details/118031810

RocketMQ 专栏收录该内容

11 篇文章

订阅专栏

学习MQ之前我们需要知道，为什么要去学习MQ呢，学会了MQ对我们有什么用呢？又在那些场景中会用到MQ呢？在使用MQ的过程中要需要注意那些问题呢？在实践过程中遇到问题如何解决呢？下面我们带着这些问题开始初步学习MQ?

首先说下MQ的作用

MQ作用大致可以分为三大类：1:异步 2:解耦 3:削峰

具体哪例子讲解下：

异步

例子：快递员发快递，直接到客户家效率会很低。引入菜鸟驿站后，快递员只需要把快递放到菜鸟驿站，就可以继续发其他快递去了。客户再按自己的时间安排去菜鸟驿站取快递。

作用：异步能提高系统的响应速度、吞吐量。

解耦

例子：《Thinking in JAVA》很经典，但是都是英文，我们看不懂，所以需要编辑社，将文章翻译成其他语言，这样就可以完成英语与其他语言的交流。

作用：

1、服务之间进行解耦，才可以减少服务之间的影响。提高系统整体的稳定性以及可扩展性。

2、另外，解耦后可以实现数据分发。生产者发送一个消息后，可以由一个或者多个消费者进行消费，并且消费者的增加或者减少对生产者没有影响。

削峰

例子：长江每年都会涨水，但是下游出水口的速度是基本稳定的，所以会涨水。引入三峡大坝后，可以把水储存起来，下游慢慢排水。

作用：以稳定的系统资源应对突发的流量冲击。

MQ的常见应用场景有那些

MQ 可应用在多个领域，包括异步通信解耦、企业解决方案、金融支付、电信、电子商务、

快递物流、广告营销、社交、即时通信、手游、视频、物联网、车联网等。从应用功能上来

讲。

例如：

日志监控，作为重要日志的监控通信管道，将应用日志监控对系统性能影响降到最低。

消息推送，为社交应用和物联网应用提供点对点推送，一对多广播式推送的能力。

金融报文，发送金融报文，实现金融准实时的报文传输，可靠安全。

电信信令，将电信信令封装成消息，传递到各个控制终端，实现准实时控制和信息传递。

从功能角度考虑：

RocketMQ 在实际应用中常用的使用场景、主要有异步处理，应用解耦，流量削锋和消息通

讯四个场景

使用MQ的缺点

上面也讲解了MQ的有点异步，解耦，削峰，但是在不了解MQ的情况下使用，也会对项目造成不必要的麻烦，如

系统可用性降低

系统引入的外部依赖增多，系统的稳定性就会变差。一旦MQ宕机，对业务会产生影响。这就需要考虑如何保证MQ的高可用。

系统复杂度提高

引入MQ后系统的复杂度会大大提高。以前服务之间可以进行同步的服务调用，引入MQ后，会变为异步调用，数据的链路就会变得更复杂。并且还会带来其他一些问题。比如：如何保证消费不会丢失？不会被重复调用？怎么保证消息的顺序性等问题。

消息一致性问题

A系统处理完业务，通过MQ发送消息给B、C系统进行后续的业务处理。如果B系统处理成功，C系统处理失败怎么办？这就需要考虑如何保证消息数据处理的一致性。

比较下常用的几款MQ的特性

常用的MQ产品包括Kafka、RabbitMQ和RocketMQ。我们对这三个产品做下简单的比较，重点需要理解他们的适用场景。

讲解完上面这些，大家对MQ已经有了一个初步的了解和认识，接下来讲解下MQ的基本组件：

MQ基本组件

MQ常用的几个组件就是NameSrv Broker,Product,ConSumer,Topic,Message,Queue,Tag等

NameServer

名称服务充当路由消息的提供者。生产者或消费者能够通过名字服务查找各主题相应的 Broker IP列表。多个Namesrv实例组成集群，但相互独立，没有信息交换。

主要作用：

一是维护Broker的服务地址并进行及时的更新。

二是给Producer和Consumer提供服务获取Broker列表。

相对来说，nameserver的稳定性非常高。原因有二：

1 nameserver互相独立，彼此没有通信关系，单台nameserver挂掉，不影响其他nameserver，即使全部挂掉，也不影响业务系统使用，这点类似于dubbo的zookeeper。

2 nameserver不会有频繁的读写，所以性能开销非常小，稳定性很高。无状态，动态列表；这也是和zookeeper的重要区别之一。zookeeper是有状态的。

Broker

实际处理消息存储、转发等服务的核心组件。单个broker和所有nameserver保持长连接

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

broker会每隔30秒（此时间无法更改）向所有nameserver发送心跳，心跳包含了自身的topic配置信息。

nameserver每隔10秒钟（此时间无法更改），扫描所有还存活的broker连接，若某个连接2分钟内（当前时间与最后更新时间差值超过2分钟，此时间无法更改）没有发送心跳数据，则断开连接。

当broker挂掉，心跳超时导致nameserver主动关闭连接动作：一旦连接断开，nameserver会立即感知，更新topc与队列的对应关系，但不会通知生产者和消费者每个Broker都会向每NameServer进行服务注册，这样从NameServer获取数据时无论从哪台机器上都能获取到所有的数据，而且就算其中一个NameServer宕机了，其他NameServer也能继续提供服务。

Producer

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

Consumer

消息消费者集群。通常也是业务系统中的一个功能模块。负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费 (pull consumer)、推动式消费(push consumer)

拉取式消费的应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息，应用就会启动消费过程。

推动式消费模式下Broker收到数据后会主动推送给消费端，该消费模式一般实时性较高

RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费（Broadcasting）。

集群消费模式下,相同Consumer Group的每个Consumer实例平均分摊消息。
广播消费模式下，相同Consumer Group的每个Consumer实例都接收全量的消息。

消息模型（Message Model）

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