RocketMQ-了解认识MQ

        学习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)。

  1. 集群消费模式下,相同Consumer Group的每个Consumer实例平均分摊消息。
  2. 广播消费模式下,相同Consumer Group的每个Consumer实例都接收全量的消息。
  • 消息模型(Message Model)

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

  • Topic

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

同一个Topic下的数据,会分片保存到不同的Broker上,而每一个分片单位,就叫做Message Queue。MessageQueue是生产者发送消息与消费者消费消息的最小单位。

  • 消息(Message)

消息系统所传输信息的物理载体,生产和消费数据的最小单位,每条消息必须属于一个 主题。RocketMQ中每个消息拥有唯一的Message ID,且可以携带具有业务标识的Key。 系统提供了通过Message ID和Key查询消息的功能。

  • 标签(Tag)

为消息设置的标志,用于同一主题下区分不同类型的消息。来自同一业务单元的消息, 可以根据不同业务目的在同一主题下设置不同标签。标签能够有效地保持代码的清晰度和连 贯性,并优化RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消 费逻辑,实现更好的扩展性.

以上就是本节讲解知识,主要初步认识MQ,了解MQ架构。接下来会有一篇RocketMQ的安装笔记,也是记录我自己的安装过程。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序员路同学

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值