学习MQ之前我们需要知道,为什么要去学习MQ呢,学会了MQ对我们有什么用呢?又在那些场景中会用到MQ呢?在使用MQ的过程中要需要注意那些问题呢?在实践过程中遇到问题如何解决呢?下面我们带着这些问题开始初步学习MQ?
首先说下MQ的作用
MQ作用大致可以分为三大类:1:异步 2:解耦 3:削峰
具体哪例子讲解下:
- 异步
例子:快递员发快递,直接到客户家效率会很低。引入菜鸟驿站后,快递员只需要把快递放到菜鸟驿站,就可以继续发其他快递去了。客户再按自己的时间安排去菜鸟驿站取快递。
作用:异步能提高系统的响应速度、吞吐量。
- 解耦
例子:《Thinking in JAVA》很经典,但是都是英文,我们看不懂,所以需要编辑社,将文章翻译成其他语言,这样就可以完成英语与其他语言的交流。
作用:
1、服务之间进行解耦,才可以减少服务之间的影响。提高系统整体的稳定性以及可扩展性。
2、另外,解耦后可以实现数据分发。生产者发送一个消息后,可以由一个或者多个消费者进行消费,并且消费者的增加或者减少对生产者没有影响。
- 削峰
例子:长江每年都会涨水,但是下游出水口的速度是基本稳定的,所以会涨水。引入三峡大坝后,可以把水储存起来,下游慢慢排水。
作用:以稳定的系统资源应对突发的流量冲击。
MQ的常见应用场景有那些
使用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 实例构成。
- Topic
表示一类消息的集合,每个主题包含若干条消息,每条消息只能属于一个主题,是 RocketMQ进行消息订阅的基本单位.
同一个Topic下的数据,会分片保存到不同的Broker上,而每一个分片单位,就叫做Message Queue。MessageQueue是生产者发送消息与消费者消费消息的最小单位。
- 消息(Message)
消息系统所传输信息的物理载体,生产和消费数据的最小单位,每条消息必须属于一个 主题。RocketMQ中每个消息拥有唯一的Message ID,且可以携带具有业务标识的Key。 系统提供了通过Message ID和Key查询消息的功能。
- 标签(Tag)
为消息设置的标志,用于同一主题下区分不同类型的消息。来自同一业务单元的消息, 可以根据不同业务目的在同一主题下设置不同标签。标签能够有效地保持代码的清晰度和连 贯性,并优化RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消 费逻辑,实现更好的扩展性.
以上就是本节讲解知识,主要初步认识MQ,了解MQ架构。接下来会有一篇RocketMQ的安装笔记,也是记录我自己的安装过程。