-
概述
消息（Message） 是指在应用系统之间传递的数据。消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。
消息队列（Message Queue） 是一种应用间的通信方式，也可以说是消息队列形成的模型，先进先出。消息一经发送可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，发布者和使用者都不用知道对方的存在 -
常用消息队列
RabbitMQ —— 2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一
ActiveMQ —— 一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，由Apache出品，速度很快，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能
RocketMQ —— 出自 阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更好。RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理等
Kafka —— 一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log)，之后成为Apache项目的一部分。Kafka系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。 -
常用消息队列对比
-
应用场景
应用解耦 —— 多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；
异步处理 —— 多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；
限流削峰 —— 广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；
消息驱动的系统 —— 系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；
一、异步处理应用场景举例
eg. 某网站在用户写入注册信息后需要给用户填写的邮箱和手机号分别发送注册邮件和验证短信，发送验证短信后再返回给客户端处理方式一般有串行和并行两种
1.串行方式
2.并行方式
假设三个子系统处理时间均为50ms，在不考虑网络延迟的情况下，串行的总处理时间为150ms，并行的总处理时间为100ms
3.使用消息队列
写入消息队列后，总的响应时间依赖于写入消息队列的时间，因为写入消息队列的时间可以几乎忽略不计，这种情况下是最快的
二、应用解耦应用场景举例
eg. 用户使用QQ相册上传一张图片，人脸识别系统会对该图片进行操作，此时用户并没有立即知道结果的需求
1.一般做法如下
这么做的缺点有很多：
(1) 一旦人脸识别系统调取失败就会导致图片上传失败
(2) 需要等待人脸识别系统识别完成后返回给客户端，有较高的延迟
(3) 图片上传系统与人脸识别系统之间相互调用，需要做耦合
2.如果使用消息队列
客户端上传图片后，图片上传系统将图片信息按批次写入消息队列，之后直接返回给客户端上传成功，人脸识别系统再定时或者根据开发者要求在指定时间从消息队列中获取新增图片数据，对新增图片进行人脸识别处理，实现应用解耦
三、限流削峰应用场景举例
eg. 购物网站开展秒杀活动时，由于瞬时访问量过大，导致流量暴增，相关系统无法处理请求发生崩溃
如果使用消息队列
用户请求不再直接由业务处理系统处理，消息队列进行了一个缓冲，极大缓解了业务处理系统的压力。消息队列可以对队列长度进行限制，当后请求的用户超出队列长度时，代表商品已售完，这些请求会被直接抛弃，并返回给用户商品已售完或者活动已结束的信息。 -
消息队列的两种模式
一、点对点模式
1.点对点模式包括三个角色：消息队列、发送者（生产者）、接受者（消费者）
2.特点：
(1) 每个消息只有一个接收者（Consumer），即一旦被消费，消息就不再存在消息队列中
(2) 发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运行，都不会影响到发送者下次发送消息
(3) 接收者在成功接收消息之后需要向队列应答成功，以便消息队列删除当前接收的消息
二、发布/订阅模式
1.发布/订阅模式包括三个角色：角色主题(Topic)、发布者(Publisher)、订阅者(Subscriber)
2.特点：
(1) 每个消息都可以有多个订阅者
(2) 发布者和订阅者之间有时间上的依赖性，针对某个主题的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息
(3) 为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行