MQ初识

MQ是一种理念（Message queue）

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

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

为什么要引入MQ

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

消息队列是一种“先进先出”的数据结构，生产者将消息放到消息队列中，消费者再从队列中取出消息

应用解耦

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

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

流量削峰

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

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

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

数据分发

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

异步调用

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

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

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通 过插件可以支持该协议。

标签：协议,RockerMq,队列,系统,用户,12.1,MQ,消息
来源： https://blog.csdn.net/weixin_46401545/article/details/122288440