关于JMS和MQ

2.1 什么是JMS？

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

2.2 什么是消息模型

○ Point-to-Point(P2P) --- 点对点

○ Publish/Subscribe(Pub/Sub)---  发布订阅

即点对点和发布订阅模型

2.2.1 P2P (点对点)

1、P2P

2、涉及到的概念

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

3、P2P的特点

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

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

应用场景

A用户与B用户发送消息

2.2.2Pub/Sub (发布与订阅)

Pub/Sub模式图

涉及到的概念

主题（Topic）

发布者（Publisher）

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

Pub/Sub的特点

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

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

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

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

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

发布订阅模式：

消息容器 类似队列

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

原则： 先进先出原则

生产者 消费者  消息容器

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

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

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

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

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

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

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

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

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

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

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

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

1 特性：

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

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

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

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

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

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

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

队列里存放消息集合

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

应用场景:

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

画图演示

异步处理

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

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

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

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

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

这样提高程序效率

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

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

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

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

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

1、控制活动人数

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

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

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

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