关于JMS和MQ

2.1 什么是JMS？

JMS是java的消息服务，JMS的客户端之间能够经过JMS服务进行异步的消息传输。

2.2 什么是消息模型

○ Point-to-Point(P2P) --- 点对点 ○ Publish/Subscribe(Pub/Sub)---  发布订阅

即点对点和发布订阅模型

2.2.1 P2P (点对点)

一、P2P

二、涉及到的概念 

 

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

 三、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方法。

 

发布订阅模式：

消息容器 相似队列

队列里面存放多个消息，消息容器里面能够存放多个队列

原则： 先进先出原则

 生产者 消费者  消息容器

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

 

 

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

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

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

 

 

若是消费者宕机了，消息会丢失吗？

不会的。缘由消息存在队列里面的。队列中存放消息，若是消费者没有及时消费的话，都会存放在消息队列中。

 

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

 

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

 

  

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

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

     消息消费者能够随时消费队列中的消息

   

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

1 特性： 

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

   主题中的消息被全部订阅者消费

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

 

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

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

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

 

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

  队列里存放消息集合

 

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

 

 

 

应用场景:

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

   画图演示

 

 

 

 

 

异步处理

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

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

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

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

    

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

 

这样提升程序效率

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

 

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

 

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

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

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

一、控制活动人数

二、缓解短期内流量压垮应用

 

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

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

 

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