JMS（Java Messaging Service）是Java平台上有关面向消息中间件的技术规范，其实是一套api，它便于消息系统中的Java应用程序进行消息交换,而且经过提供标准的产生、发送、接收消息的接口简化企业应用的开发，消息中间件是这个规范的一个具体实现。前端

JMS规范中的消息

JMS 消息由如下三部分组成：数据库

· 消息头。每一个消息头字段都有相应的getter 和setter 方法。
· 消息属性。若是须要除消息头字段之外的值，那么可使用消息属性。
· 消息体。JMS 定义的消息类型有TextMessage、MapMessage、BytesMessage、StreamMessage 和 ObjectMessage。

JMS消息模型

Point-to-Point(P2P) / 点对点api

消息经过称为队列的一个虚拟通道来进行交换。队列是生产者发送消息的目的地和接受者消费消息的消息源。服务器

每条消息通仅会传送给一个接受者。可能会有多个接受者在一个队列中侦听，可是每一个队列中的消息只能被队列中的一个接受者消费。网络

消息存在前后顺序。一个队列会按照消息服务器将消息放入队列中的顺序，把它们传送给消费者当消息已被消费时，就会从队列头部将它们删除。架构

每一个消息只有一个消费者（Consumer）(即一旦被消费，消息就再也不在消息队列中)并发

发送者发送了消息以后，无论接收者有没有正在运行，它不会影响到消息被发送到队列异步

接收者在成功接收消息以后需向队列应答成功性能

若是但愿发送的每一个消息都应该被成功处理的话，使用这个P2P模式。spa

一、消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不一样，发布到topic的消息会被全部订阅者消费。

二、若是你但愿发送的消息能够不被作任何处理、或者被一个消息者处理、或者能够被多个消费者处理的话，那么能够采用topic模型

常见的消息中间件

1、异步处理

场景说明：用户注册后，须要发注册邮件和注册短信。传统的作法有两种1.串行的方式；2.并行方式。

串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务所有完成后，返回给客户端。

（2）并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差异是，并行的方式能够提升处理的时间。

假设三个业务节点每一个使用50毫秒钟，不考虑网络等其余开销，则串行方式的时间是150毫秒，并行的时间多是100毫秒。

小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？

引入消息队列，将不是必须的业务逻辑，异步处理。

按照以上约定，用户的响应时间至关因而注册信息写入数据库的时间，也就是50毫秒。注册邮件，发送短信写入消息队列后，直接返回，所以写入消息队列的速度很快，基本能够忽略，所以用户的响应时间多是50毫秒。所以架构改变后，系统的吞吐量提升到每秒20 QPS。比串行提升了3倍，比并行提升了两倍。

2、应用解耦

场景说明：用户下单后，订单系统须要通知库存系统。传统的作法是，订单系统调用库存系统的接口。

传统模式的缺点：

1）假如库存系统没法访问，则订单减库存将失败，从而致使订单失败；

2）订单系统与库存系统耦合；

如何解决以上问题呢？引入应用消息队列后的方案

订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。

库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操做。

假如：在下单时库存系统不能正常使用。也不影响正常下单，由于下单后，订单系统写入消息队列就再也不关心其余的后续操做了。实现订单系统与库存系统的应用解耦。

3、流量削峰

流量削峰也是消息队列中的经常使用场景，通常在秒杀或团抢活动中使用普遍。

应用场景：秒杀活动，通常会由于流量过大，致使流量暴增，应用挂掉。为解决这个问题，通常须要在应用前端加入消息队列：能够控制活动的人数；能够缓解短期内高流量压垮应用。

用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面；秒杀业务根据消息队列中的请求信息，再作后续处理。

4、日志处理

日志处理是指将消息队列用在日志处理中，好比Kafka的应用，解决大量日志传输的问题。架构简化以下：

日志采集客户端，负责日志数据采集，定时写入Kafka队列：Kafka消息队列，负责日志数据的接收，存储和转发；日志处理应用：订阅并消费kafka队列中的日志数据。