学习目标
- 能够说出MQ的应用场景
- 能够编写RabbitMQ收发消息的入门程序
- 能够说出工作队列模型的特点
- 能够说出发布订阅模型的交换机类型
- 能够说出fanout交换机的特性
- 能够说出Direct交换机的特性
- 能够说出Topic交换机的特性
- 能够说出惰性队列的特性
- 能够说出优先级队列的特性
- 能够说出如何解决MQ消息堆积问题
- 能够在商城项目应用MQ
1.初识MQ
1.1 同步调用与异步调用
前边我们学习了微服务之间远程调用方式，通常服务端提供HTTP RESTful接口，客户端通过HTTP Client工具进行远程调用，远程调用工具有RestTemplate、OpenFeign、OkHttp等技术，这些技术实现的都是一种类型即同步调用，微服务之间通信还有一种异步调用，什么是同步调用？什么是异步调用？
拿订单支付功能举例，下图表示了同步调用
支付的交互流程如下：
- 支付服务调用用户服务扣减余额。
- 余额扣减成功后支付服务更新数据库中的交易流水状态为已支付。
- 更新成功后支付服务调用交易服务更新订单状态为已支付。
像这种每一步调用者必须等待被调用方完全执行完毕并返回结果之后才能继续执行后续代码，叫同步调用。
同步调用就是顺序执行，执行完一步再执行下一步。
什么是异步调用？
异步调用是调用者发出调用后无需等待被调用方完成就可以继续执行其他任务。
举例：
支付的交互流程如下：
- 支付服务调用用户服务扣减余额。
- 余额扣减成功后支付服务更新数据库中的交易流水状态为已支付。
- 更新交易流水成功支付服务向消息中间件发消息（XX订单支付成功），此时支付服务程序执行结束
- 由消息中间件去通知交易服务更新订单状态
- 由消息中间件去通知短信服务通知用户订单支付成功啦
上边交互流程中前3步为同步调用，后2步为异步调用。
支付服务向消息中间件发过消息后不用等继续执行其它操作，这就是异步调用。
现在生活中异步调用的例子很多：
餐厅点餐：
想象一下你去一家餐厅吃饭，你坐下后，服务员过来让你点菜。在这个过程中：
- 异步调用：你告诉服务员你想要什么菜品，然后服务员把订单送到厨房。你不需要等待食物准备完成，可以继续聊天或浏览菜单。当食物准备好时，服务员会将食物端到你的桌上。
- 同步调用：如果你必须站在厨房门口等着厨师为你准备食物，那么这就是一个同步的过程。你无法做其他事情，直到食物准备完毕。
医院挂号：
- 异步调用：打电话挂号，接通电话你告诉工作人员挂哪个科室，工作人员让你挂断电话稍后通过手机查看挂号结果。
- 同步调用：打电话挂号，接通电话你告诉工作人员挂哪个科室，工作人员开始查看该科室是否有号，并进行挂号，挂号结束告诉你几点来看病，最后挂断电话。
同步调用：
特点：
- 在同步调用中，调用者必须等待被调用方完全执行完毕并返回结果之后才能继续执行后续代码。
- 控制流是线性的，即程序按照顺序执行每个操作。
- 如果被调用方执行时间较长，那么整个程序会处于等待状态，直到该调用完成。
适合场景：
- 对实时性要求较高的场景，例如用户界面操作。
- 调用简单且执行快速的操作。
优点
- 简单直观：代码易于理解和编写，因为它是按顺序执行的。
- 易于调试：由于执行顺序明确，调试起来相对容易。
缺点
- 阻塞执行：如果一个操作需要很长时间来完成，那么整个程序会被阻塞，不能执行其他任务。
- 资源浪费：在等待长时间操作完成时，CPU和其他资源可能会处于空闲状态。
异步调用：
特点：
- 在异步调用中，调用者发出调用后无需等待被调用方完成就可以继续执行其他任务。
- 被调用方完成操作后，通常会通过回调函数、事件通知或者完成信号等方式告知调用者。
- 可以提高程序的并发能力和响应速度。
适合场景：
- 需要处理耗时操作，例如网络请求、文件I/O等。
- 多个操作之间不存在严格的依赖关系。
- 对系统性能和响应时间有较高要求的应用场景。
优点
- 提高效率：异步调用可以使程序在等待某些耗时操作完成的同时执行其他任务，提高整体执行效率。
- 资源利用率高：在等待耗时操作时，可以释放资源给其他任务使用，避免了资源浪费。
- 更好的用户体验：在网络应用中，用户不必等待页面加载完成就能进行其他操作，提高了用户体验。
缺点
- 复杂性增加：异步编程通常比同步编程更复杂，因为它涉及更多的控制结构和错误处理逻辑。
- 调试困难：由于执行路径不是线性的，调试起来相对困难。
1.2 初识MQ
异步调用方式其实就是基于消息通知的方式，一般包含三个角色：
- 消息发送者：投递消息的人，就是原来的调用方
- 消息Broker(消息代理/消息中间件)：管理、暂存、转发消息，你可以把它理解成微信服务器
- 消息接收者：接收和处理消息的人，就是原来的服务提供方
在异步调用中，发送者不再直接同步调用接收者的业务接口，而是发送一条消息投递给消息Broker。然后接收者根据自己的需求从消息Broker那里订阅消息。每当发送方发送消息后，接收者都能获取消息并处理。
这样，发送消息的人和接收消息的人就完全解耦了。
消息Broker，目前常见的实现方案就是消息队列（MessageQueue），简称为MQ.
AI:消息队列的应用场景
- 异步处理:
- 场景: 当应用程序需要执行耗时的操作（如发送电子邮件、文件上传或下载等）时，可以将这些任务发送到消息队列中，由专门的任务处理程序异步执行。
- 好处: 减少了用户的等待时间，提高了用户体验。
- 解耦:
- 场景: 当一个系统由多个组件组成时，这些组件之间可以使用消息队列进行通信。
- 好处: 单个组件的变化不会直接影响到其他组件，提高了系统的可扩展性。
- 流量削峰
- 场景：在许多互联网应用和服务中，尤其是那些具有明显周期性流量特征的应用（如电商平台、社交网络等），常常会遇到流量突增的情况。例如，在电商促销期间，大量的用户会在短时间内访问网站并提交订单，这种短时间内产生的巨大流量可能会导致服务器过载，影响用户体验甚至导致服务不可用。
- 好处：当流量激增时接收到请求会被暂时存储在消息队列中，而不是直接发送到后端服务进行处理。这样做可以避免后端服务因为短时间内处理大量请求而过载。后端服务可以从消息队列中按需拉取消息进行处理。这种异步处理机制可以有效地分散流量峰值，确保后端服务的稳定运行。如下图：
目比较常见的MQ实现：
- ActiveMQ：https://activemq.apache.org/
- RabbitMQ：https://www.rabbitmq.com/
- RocketMQ：https://rocketmq.apache.org/
- Kafka：https://kafka.apache.org/
几种常见MQ的对比：
- 追求可靠性：RabbitMQ、RocketMQ
- 追求吞吐（高并发）能力：RocketMQ、Kafka
- 追求消息低延迟：RabbitMQ、Kafka
这四种的MQ在市场都是非常流行，本课程讲解RabbitMQ。
Spring Boot默认支持AMQP协议，RabbitMQ支持AMQP协议 。
