关于JMS和MQ

短命女 2022-01-28 11:23 278阅读 0赞

# [关于JMS和MQ][JMS_MQ] #

## 2.1 什么是JMS？ ##

JMS是java的消息服务，JMS的客户端之间可以通过JMS服务进行异步的消息传输。

## 2.2 什么是消息模型 ##

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"> <p>○ Point-to-Point(P2P) --- 点对点</p> <p>○ Publish/Subscribe(Pub/Sub)---&nbsp; 发布订阅</p> </td> 
  </tr> 
 </tbody> 
</table>

即点对点和发布订阅模型

### 2.2.1 P2P (点对点) ###

1、P2P

![1179709-20181109171841365-1672500400.png][]

2、涉及到的概念

1.  1.  消息队列（Queue）
    2.  发送者(Sender)
    3.  接收者(Receiver)
    4.  每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。

3、P2P的特点

1.  每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)
2.  发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列
3.  接收者在成功接收消息之后需向队列应答成功

如果你希望发送的每个消息都应该被成功处理的话，那么你需要P2P模式。

应用场景

A用户与B用户发送消息

### 2.2.2Pub/Sub (发布与订阅) ###

Pub/Sub模式图

![1179709-20181109172012205-271418318.png][]

涉及到的概念

主题（Topic）

发布者（Publisher）

订阅者（Subscriber）   
客户端将消息发送到主题。多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。

Pub/Sub的特点

每个消息可以有多个消费者

发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息，而且为了消费消息，订阅者必须保持运行的状态。

为了缓和这样严格的时间相关性，JMS允许订阅者创建一个可持久化的订阅。这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。

如果你希望发送的消息可以不被做任何处理、或者被一个消息者处理、或者可以被多个消费者处理的话，那么可以采用Pub/Sub模型

消息的消费   
在JMS中，消息的产生和消息是异步的。对于消费来说，JMS的消息者可以通过两种方式来消费消息。   
○ 同步   
订阅者或接收者调用receive方法来接收消息，receive方法在能够接收到消息之前（或超时之前）将一直阻塞   
○ 异步   
订阅者或接收者可以注册为一个消息监听器。当消息到达之后，系统自动调用监听器的onMessage方法。

发布订阅模式：

消息容器 类似队列

队列里面存放多个消息，消息容器里面可以存放多个队列

原则： 先进先出原则

生产者 消费者  消息容器

消费者和消息容器建立长链接   一旦生产者发布消息后   推送退给 消费者（监听）

![1179709-20190308011227685-587576222.png][]

上图中： 容器中可以存放多个队列，一个队列里面存放多个消息。

原则：先进先出，后进后出

消息：生产者与消费者之间传递数据

如果消费者宕机了，消息会丢失吗？

不会的。原因消息存在队列里面的。队列中存放消息，如果消费者没有及时消费的话，都会存放在消息队列中。

消息中间件可以解决高并发问题，流量削锋问题，如果生产者上产一万个消息，消费者每次只能一千个消息消费。

整个过程属于异步方式的。

![1179709-20181109175828827-2020028038.png][]

1、生产者发送一条消息到queue，只有一个消费者能收到     （一对一模式）

2、客户端包括生产者和消费者 队列中的消息只能被一个消息消费者消费

消息消费者可以随时消费队列中的消息

![1179709-20181109180142119-225951292.png][]

1、发布者发送套tipic的消息，只有订阅了topic的订阅者才会收到消息

1 特性：

客户端暴扣发布者和订阅者

主题中的消息被所有订阅者消费

消费者不能消费订阅之前就发送到主题中的消息

发布订阅和点对点通讯方式的却别：

点对点  只能保证一个消费者进行消费

发布订阅 只要集群服务订阅该主题都会收到消息 一对多

下次队列指的是生产者与消费者传递数据

队列里存放消息集合

消息中间件包括 消息队列 和 发布订阅

应用场景:

用户注册、订单修改库存、日志存储

画图演示

![1179709-20181109172106486-128203240.png][]

![1179709-20181109172118603-799739316.png][]

![1179709-20181109172132425-690027852.png][]

异步处理

场景说明：用户注册后，需要发注册右键和注册短信。传统的做法两种：

1、串行方式    将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。串行方式： 一步一步走  是同步的过程  单线程的

2、并行方式   将信息写入数据库成功后，发送注册邮件的同时，发送注册短信。完成任务后，返回给客户端，与串行的区别是，并行方式可以提高处理的时间

2、引入消息队列。将不是必须的业务逻辑异步处理。用户响应时间相当于是注册信息写入数据库的时间，也就是50毫秒。注册邮件发送短信写入消息队列后，直接返回。因此写入消息队列的速度很快，基本可以忽略，因此用户的响应时间可能是50毫秒。系统的吞吐量提高到每秒20 QPS，比串行提高了3倍，比并行提高了2倍。

将发送邮件、短信内容以MQ异步进行消费

![1179709-20190308012243074-683290412.png][]

这样提高程序效率

如果消费者发送短信或者邮件消费失败的话，MQ自带重合和补偿机制。

耗时间的接口 统一采用MQ推送  不建议使用激光同步方式

消息队列应用场景 流量削峰的使用

流量削峰是消息队列汇总的常用场景，一般再秒杀或者团抢活动中使用

秒杀活动，一般回应为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要再应用其那段加入消息队列。

1、**控制活动人数**

2、**缓解短时间内流量压垮应用**

![1179709-20190308011659601-1373766052.png][]

用户的请求，服务器接受后，首先写入消息队列。加入消息队列长度超过最大数量，则直接抛弃用户请求或者跳转错误页面

秒杀业务根据消息队列中的请求信息，在做后续处理

秒杀：  Redis+MQ+服务保护机制（服务降级、隔离、熔断）+服务限流+图像验证码+token

[JMS_MQ]: https://www.cnblogs.com/toov5/p/9936517.html
[1179709-20181109171841365-1672500400.png]: /images/20220128/a0de117ffbaa4a17ab4543beb511a7ff.png
[1179709-20181109172012205-271418318.png]: /images/20220128/8a21fa6083dd4f249c6feea1337ffc42.png
[1179709-20190308011227685-587576222.png]: /images/20220128/f96a1b6c13e841c18f53a3360b9777f8.png
[1179709-20181109175828827-2020028038.png]: /images/20220128/65029f74c3804ca591aa15db998f99b7.png
[1179709-20181109180142119-225951292.png]: /images/20220128/1fe4db5d6b144db29be3275ecac7a4ee.png
[1179709-20181109172106486-128203240.png]: /images/20220128/794b15543a654eac9bac9f5d6deae783.png
[1179709-20181109172118603-799739316.png]: /images/20220128/b1053175a2e04b42b5139139c3e15e1f.png
[1179709-20181109172132425-690027852.png]: /images/20220128/9575d69d919b4d4f9606bad817603e1b.png
[1179709-20190308012243074-683290412.png]: /images/20220128/7d922373ffec43249524e8508b0d3cf4.png
[1179709-20190308011659601-1373766052.png]: /images/20220128/9fca6e09f2964240b79eb33c940ba0b7.png