2.1 什么是JMS？
JMS是Java的消息服务，JMS的客户端之间可以通过JMS服务进行异步的消息传输。
2.2 什么是消息模型
|
○ Point-to-Point(P2P) --- 点对点 ○ Publish/Subscribe(Pub/Sub)--- 发布订阅 |
即点对点和发布订阅模型
2.2.1 P2P (点对点)
1、P2P
2、涉及到的概念
- 消息队列（Queue）
- 发送者(Sender)
- 接收者(Receiver)
- 每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。
3、P2P的特点
- 每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)
- 发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列
- 接收者在成功接收消息之后需向队列应答成功
如果你希望发送的每个消息都应该被成功处理的话，那么你需要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