开发者学堂课程【全面讲解 Spring Cloud Alibaba 技术栈（知识精讲+项目实战）第四阶段：MQ 介绍】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/686/detail/11902
MQ 介绍
内容介绍：
一、MQ 简介
二、MQ 的应用场景
三、常见的 MQ 产品
一、MQ 简介
1、什么是 MQ
MQ (Message Queue 消息队列)是一种跨进程的通信机制，用于传递消息。通俗点说，就是一个先进先出的数据结构。
左边是消息生产者，将生产好的消息从管道的左边放到管道里面，然后右边消息消费者可以从管道里取出里面的消息来使用，整个管道也就是 MQ 起到的作用是临时存储和传递消息，这就是 MQ 的简单介绍。
为什么需要 MQ 在中间，直接消息生产者生产完消息给消息消费者来用不可以吗，MQ 有必要存在吗？接下来画一张图把 MQ 去掉看一看有什么样的问题存在。左边是消息生产者，右边是消息的消费者。如果没有 MQ 存在，消息消费者会调用消息生产者的消息来用。调用有大约两种方式。
调用方式:
RESTFUL
RPC
紧密耦合(高内聚 低耦合)
第一种是基于 RESTFUL 风格的 HDTP 协议，第二种是远程 RPC，无论哪一种调用方式都存在一个问题是消息生产者和消息消费者的关系是紧密耦合的。
在 IT 界有一个词叫高内聚低耦合，现在模型是违反原则的，需要思考如何能让消息生产者和消费者进行解耦，在中间放消息临时存储的地方。
作为消息生产者将生产好的消息直接放到 MQ 里面，不管消息消费者是否消费，放进去事情就做完了，而消息消费者不管生产者是什么时候生产的，只需要需要对接到 MQ 上，只要 MQ 里面有消息取出来用就可以，消息生产者和消费者不会直接去打交道，起到了解耦合的作用，MQ 的作用是用于消息的耦合。
二、MQ 的应用场景
1、异步解耦
（1）传统做法
最常见的一个场景是用户注册后，需要发送注册邮件和短信通知，以告知用户注册成功。
传统的做法如下:
传统方式下首先用户通过注册页面向注册系统提交注册请求，然后注册系统会将提交的信息保存到数据库中，当信息保存完毕之后真正的注册流程已经结束，接下来的流程是发送通知的流程，注册系统会首先调用邮件通知系统发送一条邮件通知，等到返回成功的结果之后，再去调用短信通知系统发送短信的通知，等到短信的通知也返回正确的结果之后，注册系统才会将注册成功的页面返回用户，这就是传统方式下如何来处理注册的需求的。
方式的问题在于在这样一个架构中注册、邮件、短信是绑定在一起的，用户需要等待三个系统都处理完毕之后才能拿到注册成功的页面。比如注册系统要用五秒钟的时间来处理注册请求，邮件和短信也都需要五秒钟来处理，意味着用户至少要等待15秒才能拿到成功结果，这15秒钟只有注册系统 5秒是用户必须要等待的，因为对于用户注册用户并不是特别关注后面两个通知，只要注册信息被写入数据库用户就能够去登录，在场景下大大的需要浪费用户的时间，需要在注册系统后加入 MQ 消息队列。
此架构下注册、邮件、短信三个任务全部完成后，才返回注册结果到客户端，用户才能使用账号登录。但是对于用户来说，注册功能主际只需要注册系统存储用户的账户信息后，该用户便可以登录，而后续的注册短信和邮件不是即时需要关注的步骤。
（2）加入 MQ 消息队列
所以实际当数据写入注册系统后，注册系统就可以把其他的操作放入对应的消息队列 MQ 中然后马上返回用户结果，由消息队列 MQ 异步地进行这些操作。架构图如下:
用户发送注册请求给注册系统去向数据库写入信息，当写入信息完毕之后，不再去直接调用邮件和短信通知系统，而是将注册成功的消息写入到 MQ 中期，只要 MQ 已经接收到消息拿到响应结果，立刻将成功的页面展示给用户就可以，后续的像邮件通知、短信通知相当于注册系统已经解开耦合不再去关注邮件和短信通知系统工作，邮件通知和短信通知会对 MQ 实行监听，一旦发现 MQ 有消息存入就会对消息进行消费，然后取出消息发送对应的邮件和短信通知。
在这种情况下，耗时因为只要消息存过去就可以不用去等待发送，整个过程可能需要六秒钟，对比起原来的15秒钟已经是大大的节约客户的时间，这就是 MQ 如何在用户注册场景下进行的工作原理，总结起来是让两短期通知变成异步操作，然后放一个 MQ 解开，注册系统和通知系统的耦合。
异步解耦是消息队列 MQ 的主要特点，主要目的是减少请求响应时间和解耦。主要的使用场景就是将比较耗时而且不需要即时(同步)返回结果的操作作为消息放入消息队列。
同时，由于使用了消息队列 MQ，只要保证消息格式不变，消息的发送方和接收方并不需要彼此联系，也不需要受对方的影响，即解耦合。
2、流量削峰
流量削峰也是消息队列 MQ的常用场景，一般在秒杀或团队抢购（高并发）活动中使用广泛。
在秒杀或团队抢购活动中，由于用户请求量较大，导致流量暴增，秒杀的应用在处理如此大量的访问流量后，下游的通知系统无法承载海量的调用量，甚至会导致系统崩溃等问题而发生漏通知的情况。为解决这些问题，可在应用和下游通知系统之间加入消息队列 MQ 。
先忽略掉中间的 MQ 意味着秒杀系统一旦秒杀成功就立即向通知系统发送消息，要求通知系统发送另外通知，秒杀肯定是高并发的要做特殊处理，能承受住海量数据并不意味着通知系统也能承受住海量数据，把通知做的跟秒杀一样能够承受住海量数据就要考虑到成本的问题，秒杀不得不这样做但是通知没有必要，这时候可以当秒杀成功以后先将消息推到 MQ 中，MQ 起到缓冲和暂时存储的作用，然后通知系统再去监测 MQ，慢慢的从里面取消息来消费就可以，流量的削峰就是通过MQ的缓冲功能将高峰消掉。
秒杀处理流程如下所述:
（1）用户发起海星秒杀请求到秒杀业务处理系统。
（2）秒杀处理系统按照秒杀处理逻辑将满足秒杀条件的请求发送至消息队列 MQ
（3）下游的通知系统订阅消息队列 MO 的秒杀相关消息，再将秒杀成功的消息发送到相应用户。
（4）用户收到秒杀成功的通知。
三、常见的 MQ 产品
1、MQ 产品
目前业界有很多 MQ 产品，比较出名的有下面这些:
（1）ZeroMQ
号称最快的消息队列系统，尤其针对大吞吐星的需求场景。扩展性好，开发比较灵活，采用 C 语言实现，实际上只是一个 socket 库的重新封装，如果做为消息队列使用，需要开发大量的代码。ZeroMQ 仅提供非持久性的队列，也就是说如果 down 机，数据将会丢失。（没有持久化机制）
（2）RabbitMQ
使用 erlang 语言开发，性能较好，适合于企业级的开发。但是不利于做二次开发和维护。（会的人比较少）
（3）ActiveMQ
历史悠久的 Apache 开源项目。已经在很多产品中得到应用，实现了 JMS1.1 规范，可以和 spring-jms 轻松融合，实现了多种协议，支持持久化到数据库，对队列数较多的情况支持不好。
（4）RocketMQ
阿里巴巴的 MQ 中间件，由 java 语言开发，性能非常好，能够撑住双十一的大流量，而且使用起来很简单。
（5）Kafka
Kafka是 Apache 下的一个子项目，是一个高性能跨语言分布式 Publish/Subscribe 消息队列系统，相对于 ActiveMQ 是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。（在现在大数据行业比较流行）
