消息队列(MQ)
什么是消息队列
消息队列不知道大家看到这个词的时候，会不会觉得它是一个比较高端的技术。消息队列，一般我们会简称它为MQ（Message Queue）.
消息队列是一种帮助开发人员解决系统间异步通信的中间件，常用于解决系统解耦和请求的削峰平谷的问题。
队列（Queue）：
Queue 是一种先进先出的数据结构，容器
消息（Message）：
不同应用之间传送的数据。
消息队列：
我们可以把消息队列比作是一个存放消息的容器，当我们需要使用消息的时候可以取出消息供自己使用。消息队列是分布式系统中重要的组件，使用消息队列主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性。队列 Queue 是一种先进先出的数据结构，所以消费消息时也是按照顺序来消费的。比如生产者发送消息1,2,3...对于消费者就会按照1,2,3...的顺序来消费。
传统方式
MQ方式
消息队列的应用场景
消息队列在实际应用中包括如下四个场景：
- 应用耦合： 多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；
- 异步处理： 多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；
- 限流削峰： 广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；
- 消息驱动的系统： 系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理
下面详细介绍上述四个场景以及消息队列如何在上述四个场景中使用
异步处理
具体场景：
用户为了使用某个应用，进行注册，系统需要发送注册邮件并验证短信。
对这两个子系统操作的处理方式有两种：串行及并行。
涉及到三个子系统：注册系统、邮件系统、短信系统
- 串行方式：新注册信息生成后，先发送注册邮件，再发送验证短信
在这种方式下，需要最终发送验证短信后再返回给客户端。
- 并行处理：新注册信息写入后，由发短信和发邮件并行处理
在这种方式下，发短信和发邮件 需处理完成后再返回给客户端。
假设以上三个子系统处理的时间均为50ms，且不考虑网络延迟，则总的处理时间：
串行：50+50+50=150ms
并行：50+50 = 100ms
如果引入消息队列, 在来看整体的执行效率:
在写入消息队列后立即返回成功给客户端，则总的响应时间依赖于写入消息队列的时间，而写入消息队列的时间本身是可以很快的，基本可以忽略不计，因此总的处理时间为50ms，相比串行提高了2倍，相比并行提高了一倍；
应用耦合
具体场景：
用户使用QQ相册上传一张图片，人脸识别系统会对该图片进行人脸识别。
一般的做法是，服务器接收到图片后，图片上传系统立即调用人脸识别系统，调用完成后再返回成功，如下图所示:
调用方式：webService、Http协议（HttpClient、RestTemplate)、Tcp协议（Dubbo）
该方法有如下缺点:
1) 人脸识别系统被调失败，导致图片上传失败；
2) 延迟高，需要人脸识别系统处理完成后，再返回给客户端，即使用户并不需要立即知道结果；
3) 图片上传系统与人脸识别系统之间互相调用，需要做耦合；
复制代码若使用消息队列:
客户端上传图片后，图片上传系统将图片信息批次写入消息队列，直接返回成功；
人脸识别系统则定时从消息队列中取数据，完成对新增图片的识别。
图片上传系统并不需要关心人脸识别系统是否对这些图片信息的处理、以及何时对这些图片信息进行处理。
事实上，由于用户并不需要立即知道人脸识别结果，人脸识别系统可以选择不同的调度策略，按照闲时、忙时、正常时间，对队列中的图片信息进行处理。
限流削峰
具体场景：
购物网站开展秒杀活动，一般由于瞬时访问量过大，服务器接收过大，会导致流量暴增，相关系统无法处理请求甚至崩溃。
而加入消息队列后，系统可以从消息队列中取数据，相当于消息队列做了一次缓冲。
该方法有如下优点：
请求先入消息队列，而不是由业务处理系统直接处理，做了一次缓冲,极大地减少了业务处理系统的压力；
队列长度可以做限制，事实上，秒杀时，后入队列的用户无法秒杀到商品，这些请求可以直接被抛弃，返回活动已结束或商品已售完信息；
消息事件驱动的系统
具体场景：
用户新上传了一批照片 ---->人脸识别系统需要对这个用户的所有照片进行聚类 -------> 由对账系统重新生成用户的人脸索引（加快查询）。
这三个子系统间由消息队列连接起来，前一个阶段的处理结果放入队列中，后一个阶段从队列中获取消息继续处理。
该方法有如下优点：
避免了直接调用下一个系统导致当前系统失败；
每个子系统对于消息的处理方式可以更为灵活，可以选择收到消息时就处理，可以选择定时处理，也可以划分时间段按不同处理速度处理；
消息队列的两种模式
消息队列包括两种模式，点对点模式（point to point， queue）和发布/订阅模式（publish/subscribe，topic）
点对点模式
点对点模式下包括三个角色
- 消息队列
- 发送者 (生产者)
- 接收者（消费者）
每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，可以放在内存 中也可以持久化，直到他们被消费或超时。
点对点模式特点：
- 每个消息只有一个消费者，一旦被消费，消息就不再在消息队列中；
- 发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运行，都不会影响到发送者下次发送消息；
- 接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息；
发布/订阅模式
发布/订阅模式下包括三个角色：
- 角色主题（Topic）
- 发布者(Publisher)
- 订阅者(Subscriber)
消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被多个订阅者消费。
发布/订阅模式特点：
- 每个消息可以有多个订阅者；
- 发布者和订阅者之间有时间上的依赖性
- 为了消费消息，订阅者必须保持在线运行。
消息队列实现机制
JMS
JMS（JAVA Message Service，Java消息服务）是一个Java平台中关于面向消息中间件的API
允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息
是一个消息服务的标准或者说是规范，是 Java 平台上有关面向消息中间件的技术规范
便于消息系统中的 Java 应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口，简化企业应用的开发。
JMS 消息机制主要分为两种模型：PTP 模型和 Pub/Sub 模型。
实现产品：Apache ActiveMQ
AMQP
AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。Erlang中的实现有RabbitMQ等。
JMS VS AMQP
| JMS | AMQP | |
|---|---|---|
| 定义 | Java api | Wire-protocol |
| 跨语言 | 否 | 是 |
| 跨平台 | 否 | 是 |
| Model | 提供两种消息模型/模式：（1）、Peer-2-Peer（2）、Pub/sub | 提供了五种消息模型：（1）、direct exchange（2）、fanout exchange（3）、topic change（4）、headers exchange（5）、system exchange本质来讲，后四种和JMS的pub/sub模型没有太大差别，仅是在路由机制上做了更详细的划分； |
| 支持消息类型 | 多种消息类型：TextMessage、MapMessage、BytesMessage、StreamMessage、ObjectMessage、Message （只有消息头和属性） | byte[]当实际应用时，有复杂的消息，可以将消息序列化后发送。 |
| 综合评价 | JMS 定义了JAVA API层面的标准；在java体系中，多个client均可以通过JMS进行交互，不需要应用修改代码，但是其对跨平台的支持较差； | AMQP定义了wire-level层的协议标准；天然具有跨平台、跨语言特性。 |
常见的消息队列产品
RabbitMQ
RabbitMQ 2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。
ActiveMQ
ActiveMQ是由Apache出品，ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现。它非常快速，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能
RocketMQ
RocketMQ出自 阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更
好。RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理等
Kafka
Apache Kafka是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log)，之后成为Apache项目的一部分。Kafka系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。
综合上面的材料得出以下两点:
（1）中小型软件公司:
建议选RabbitMQ.一方面，erlang语言天生具备高并发的特性，而且他的管理界面用起来十分方便。正所谓，成也萧何，败也萧何！他的弊端也在这里，虽然RabbitMQ是开源的，然而国内有几个能定制化开发erlang的程序员呢？所幸，RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug，这点对于中小型公司来说十分重要。不考虑rocketmq和kafka的原因是，一方面中小型软件公司不如互联网公司，数据量没那么大，选消息中间件，应首选功能比较完备的，所以kafka排除。不考虑rocketmq的原因是，rocketmq是阿里出品，如果阿里放弃维护rocketmq，中小型公司一般抽不出人来进行rocketmq的定制化开发，因此不推荐。
（2）大型软件公司：
根据具体使用在rocketMq和kafka之间二选一。一方面，大型软件公司，具备足够的资金搭建分布式环境，也具备足够大的数据量。针对rocketMQ,大型软件公司也可以抽出人手对rocketMQ进行定制化开发，毕竟国内有能力改JAVA源码的人，还是相当多的。至于kafka，根据业务场景选择，如果有日志采集功能，肯定是首选kafka了。