12.1(RockerMq)MQ概念

MQ初识

MQ是一种理念(Message queue)

天上飞的理念,地上的落地实现。对应着常见的四个技术

  1. ActiveMQ
  2. RabbitMQ
  3. RocketMQ
  4. kafka

为什么要引入MQ

传统生产者调用消费者使用的是RPC的调用模式,应用于应用之间耦合度极高

消息队列是一种“先进先出”的数据结构,生产者将消息放到消息队列中,消费者再从队列中取出消息
12.1(RockerMq)MQ概念

应用解耦

系统的耦合性越高,容错性就越低。以电商应用为例,用户创建订单后,如果耦合调用库存系统、物流系统、支付系统,任何一个子系统出了故障或者因为升级等原因暂时不可用,都会造成下单操作异常,影响用户使用体验。

12.1(RockerMq)MQ概念

使用消息队列解耦合,系统的耦合性就会提高了。比如物流系统发生故障,需要几分钟才能来修复,在这段时间内,物流系统要处理的数据被缓存到消息队列中,用户的下单操作正常完成。当物流系统恢复后,补充处理存在消息队列中的订单消息即可,终端系统感知不到物流系统发生过几分钟故障。

12.1(RockerMq)MQ概念

流量削峰

12.1(RockerMq)MQ概念

应用系统如果遇到系统请求流量的瞬间猛增,有可能会将系统压垮。有了消息队列可以将大量请求缓存起来,分散到很长一段时间处理,这样可以大大提到系统的稳定性和用户体验。

12.1(RockerMq)MQ概念

一般情况,为了保证系统的稳定性,如果系统负载超过阈值,就会阻止用户请求,这会影响用户体验,而如果使用消息队列将请求缓存起来,等待系统处理完毕后通知用户下单完毕,这样总不能下单体验要好。

业务系统正常时段的QPS如果是1000,流量最高峰是10000,由于高峰是短暂的,为了应对流量高峰配置高性能的服务器显然不划算,这时可以使用消息队列对峰值流量削峰

数据分发

12.1(RockerMq)MQ概念

通过消息队列可以让数据在多个系统更加之间进行流通。数据的产生方不需要关心谁来使用数据,只需要将数据发送到消息队列,数据使用方直接在消息队列中直接获取数据即可。同步的方式,新增或者删除系统都需要修改源代码。

12.1(RockerMq)MQ概念

异步调用

场景二,还是ABCD四个系统,A系统收到一个请求,需要在自己本地写库,还需要往BCD三个系统写库,A系统自己写本地库需要3ms,往其他系统写库相对较慢,B系统200ms ,C系统350ms,D系统400ms,这样算起来,整个功能从请求到响应的时间为3ms+200ms+350ms+400ms=953ms,接近一秒,对于用户来说,点个按钮要等这么长时间,基本是无法接受的,侧面也反映出这家研发人员技术不咋地。详情如下图↓↓↓↓↓↓

12.1(RockerMq)MQ概念

一般的互联网企业,对于用户请求响应的时间要求在100ms-200ms之间,这样,用户的眼睛存在视觉暂停现象,用户响应时间在此范围内就可以了,所以上面的现象是不可取的。
如果用了MQ,用户发送请求到A系统耗时3ms,A系统发送三条消息到MQ,假如耗时5ms,用户从发送请求到相应3ms+5ms=8ms,仅用了8ms,用户的体验非常好。

12.1(RockerMq)MQ概念

MQ作用总结

解耦:

  1. 不同功能模块之间是相互依赖的关系,如果下订单的时候,物流系统宕机,则会出现下订单失败的情况
  2. 使用消息队列,将物流系统原本要处理的工作存储起来,等待恢复后再进行处理,可以避免订单的失败

流量削峰:

  1. 当上线一个功能,比如商品的秒杀业务,会短时间有大量的请求访问,有可能会将系统压垮,导致订单失败
  2. 通过硬件支持短时间的巨量QPS,是十分不经济的
  3. 消息队列可以将订单请求存储分散在一个较长的时间处理,等待处理完毕再通知用户,既减轻了系统的压力,也避免了下单失败的情况

数据分发

  1. 当各个系统之间采用同步的方式进行调用,如果此时增减或者减少一个系统,需要修改源代码
  2. 利用消息队列,数据的产生方不需要关注谁来使用数据,数据使用方只需要订阅或者取消订阅消息队列即可

MQ的优点和缺点

优点:解耦、削峰、数据分发,异步

缺点包含以下几点:

  1. 如何保证MQ的高可用?
    系统引入的外部依赖越多,系统稳定性越差。一旦MQ宕机,就会对业务造成影响。
  2. 系统复杂度提高,如何保证消息没有被重复消费?怎么处理消息丢失情况?那么保证消息传递的顺序性?
    MQ的加入大大增加了系统的复杂度,以前系统间是同步的远程调用,现在是通过MQ进行异步调用。
  3. 如何保证消息数据处理的一致性?
    A系统处理完业务,通过MQ给B、C、D三个系统发消息数据,如果B系统、C系统处理成功,D系统处理失败。

常见的MQ产品

ActiveMQ

ActiveMQ是使用Java语言开发一款MQ产品。早期很多公司与项目中都在使用。但现在的社区活跃度已 经很低。现在的项目中已经很少使用了。

RabbitMQ

RabbitMQ是使用ErLang语言开发的一款MQ产品。其吞吐量较Kafka与RocketMQ要低,且由于其不是 Java语言开发,所以公司内部对其实现定制化开发难度较大。

Kafka

Kafka是使用Scala/Java语言开发的一款MQ产品。其最大的特点就是高吞吐率,常用于大数据领域的实 时计算、日志采集等场景。其没有遵循任何常见的MQ协议,而是使用自研协议。对于Spring Cloud Netçix,其仅支持RabbitMQ与Kafka。

RocketMQ

RocketMQ是使用Java语言开发的一款MQ产品。经过数年阿里双11的考验,性能与稳定性非常高。其 没有遵循任何常见的MQ协议,而是使用自研协议。对于Spring Cloud Alibaba,其支持RabbitMQ、 Kafka,但提倡使用RocketMQ

对比

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wM6IuPBy-1641196356082)(C:\Users\HP\AppData\Roaming\Typora\typora-user-images\image-20220103091112087.png)]

MQ常见协议

一般情况下MQ的实现是要遵循一些常规性协议的。常见的协议如下:

JMS

JMS,Java Messaging Service(Java消息服务)。是Java平台上有关MOM(Message Oriented Middleware,面向消息的中间件 PO/OO/AO)的技术规范,它便于消息系统中的Java应用程序进行消 息交换,并且通过提供标准的产生、发送、接收消息的接口,简化企业应用的开发。ActiveMQ是该协 议的典型实现。

STOMP

STOMP,Streaming Text Orientated Message Protocol(面向流文本的消息协议),是一种MOM设计 的简单文本协议。STOMP提供一个可互操作的连接格式,允许客户端与任意STOMP消息代理 (Broker)进行交互。ActiveMQ是该协议的典型实现,RabbitMQ通过插件可以支持该协议。

AMQP

AMQP,Advanced Message Queuing Protocol(高级消息队列协议),一个提供统一消息服务的应用 层标准,是应用层协议的一个开放标准,是一种MOM设计。基于此协议的客户端与消息中间件可传递 消息,并不受客户端/中间件不同产品,不同开发语言等条件的限制。 RabbitMQ是该协议的典型实 现。

MQTT

MQTT,Message Queuing Telemetry Transport(消息队列遥测传输),是IBM开发的一个即时通讯协 议,是一种二进制协议,主要用于服务器和低功耗IoT(物联网)设备间的通信。该协议支持所有平 台,几乎可以把所有联网物品和外部连接起来,被用来当做传感器和致动器的通信协议。 RabbitMQ通 过插件可以支持该协议。
Queuing Telemetry Transport(消息队列遥测传输),是IBM开发的一个即时通讯协 议,是一种二进制协议,主要用于服务器和低功耗IoT(物联网)设备间的通信。该协议支持所有平 台,几乎可以把所有联网物品和外部连接起来,被用来当做传感器和致动器的通信协议。 RabbitMQ通 过插件可以支持该协议。

上一篇:结构型模式之适配器模式的案例示范


下一篇:JAVA操作证书