消息队列

具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一

组成

1. Broker：消息服务器，作为server提供消息核心服务

2. Producer：消息生产者，业务的发起方，负责生产消息传broker

3. Consumer：消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理

4. Topic：主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的广播

5. Queue：队列，PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收

6. Message：消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输

模式分类

点对点

PTP点对点:使用queue作为通信载体

消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息 消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息，支持存在多个消费者，但是对一个消息而言，只会有一个消费者消费

发布订阅

Pub/Sub发布订阅（广播）：使用topic作为通信载体

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

对比：

queue实现了负载均衡，将producer生产的消息发送到消息队列中，由多个消费者消费。但一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者 topic实现了发布和订阅，当你发布一个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到一个消息的拷贝

Java消息服务（JMS）

Java消息服务（Java Message Service，JMS）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信

JMS中的P2P和Pub/Sub消息模式：点对点（point to point， queue）与发布订阅（publish/subscribe，topic）最初是由JMS定义的。这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅)

优势/应用场景

解耦：

降低工程间的强依赖程度

一方面交互系统之间没有直接的调用关系，只是通过消息传输，避免调用接口失败导致整个过程失败

另一方面通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束即可

异步处理：

消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它，在流量过大时可对响应要求不高的业务使用消息队列进行异步处理，从而提高系统响应时间

限流削峰：广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况

限流削峰/过载保护

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃

广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况

冗余（即可靠性）

有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险

许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕

顺序保证

在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理

（后面会详细介绍如何保证顺序消费）

缓冲

业务处理过程中上下流的处理速度可能是不匹配的，消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度，以调节系统响应时间

数据流处理

分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择