MQ学习前言
MQ = 消息中间件
- 消息： 微信、短信、语音…
- 中间件
MQ全称为Message Queue,消息队列(MQ)是正确而又完整的 JMS 实现,消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据（消息）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。
MQ的产品种类
从生活的例子再到生产案例
引入MQ之前和之后的对比
MQ能干嘛？
- 解耦
- 削峰
- 异步
系统之间直接调用实际工程落地和存在的问题？
微服务架构后，
链式调用是我们在写程序时候的一般流程，为了完成一个整体功能会将其拆分成多个函数（或子模块），
一个功能背后要调用上百个接口并非不可能，从单机架构过渡到分布式微服务架构的通例，
这种架构会有哪些问题？
系统之间接口耦合比较严重
每新增一个下游功能，都要对上游的相关接口进行改造；
举个例子：假如系统A要发送数据给系统B和C，发送给每个系统的数据可能有差异，因此系统A对要发送给每个系统的数据进行了组装，然后逐一发送；
当代码上线后又新增了一个需求：
把数据也发送给D，新上了一个D系统也要接收A系统的数据。此时就需要修改A系统，让她感知到D的存在，同时把数据处理好再A给D。在这个过程中你会看到，每接入一个下游系统，都要对A系统进行代码改造，开发联调的效率很低。其整体架构如下图 ：
面对大流量并发时，容易被冲垮
每个接口模块的吞吐能力是有限的，这个上限能力如果是堤坝，当大流量（洪水）来临时，容易被冲垮。
举个例子：电商秒杀业务
上游系统发起下单购买操作，我就是下单一个操作
下游系统完成秒杀业务逻辑
（读取订单，库存检查，库存冻结，余额检查，余额冻结，订单生成，余额扣减，库存扣减，生成流水，余额解冻，库存解冻）
等待同步存在性能问题
RPC接口基本上是同步调用，整体的服务性能遵循“木桶理论”，即整体系统的耗时取决于链路中最慢的那个接口。
比如A调用B/C/D都是50ms，但此时B又调用了B1，花费2000ms，那么直接就拖累了整个服务性能。
根据上述的几个问题，在设计系统时可以明确要达到的目标：
- 要做到系统解耦，当新的模块接进来时，可以做到代码改动最小；能够解耦
- 设置流量缓冲池，可以让后端系统按照自身吞吐能力进行消费，不被冲垮；能够削峰
- 强弱依赖梳理能将非关键调用链路的操作异步化并提升整体系统的吞吐能力；能够异步
定义
面向消息的中间件（message-oriented middleware）MOM能够很好的解决以上问题。
是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。
通过提供消息传递和消息排队模型在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等功能。
大致的过程是这样的：
发送者把消息发送给消息服务器，消息服务器将消息存放在若干队列/主题中，在合适的时候，消息服务器对将消息转发给接受者。在这个过程中，发送和接收使异步的，也就是发送无需等待，而且发送者和接收者的生命周期也没有必然关系；
尤其在发布pub/订阅sub模式下，也可以完成一对多的通信，即让一个消息有多个接收者。
应用系统之间的解耦合：
- 发送者和接收者不必了解对方，只需要确认消息；
- 发送者和接收者不必同时在线。
电商业务：