1、场景需求
1.1、基础知识
1.1.1、需求
在分布式场景中，相对于大量的用户请求来说，内部的功能主机之间、功能模块之间等，数据传递的数据量是无法想象的，因为一个用户请求，会涉及到各种内部的业务逻辑跳转等操作。
那么，在打用户量的业务场景中，如何保证所有的内部业务逻辑请求都处于稳定而且快捷的数据传递呢？ -- 消息队列(Message Queue)
1.1.2、消息队列
所谓的消息队列，我们可以通过名称来感受的出来，系统平台接收到的消息，临时存储到一个队列中，然后根据内部的排序机制，保证所有的消息依次到达对应的目标。消息队列不仅仅可以提高用户请求接收速度，还可以降低后端应用程序的压力。
常见的消息队列实现软件有：
专用软件：RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等
数据库功能软件：Redis、Mysq
1.1.3、功能特点
有了消息队列，原来拥挤的事务，我们可以非常轻松的进行处理了，这个特点主要体现在四个方面：
1、应用耦合：多应用模块间通信，通过消息队列进行处理，避免调用接口异常导致整个过程失败
2、异步处理：多应用模块间不用阻塞方式进行信息的处理，提高了消息并发处理的能力
3、限流削峰：避免用户流量过大导致应用系统崩溃的情况，尤其是各种突发的场景，比如秒杀、双xx活动等
4、消息驱动的系统：消息功能拆分，不同的角色进行不同功能的处理
消息发送方 : 客户端，主动发出请求给服务端，服务端接收请求后，临时存储到消息队列
消息承载队列 : 接收客户端发送过来的请求，临时存储
消息接收方 : 获取消息队列中的请求后，然后本地执行处理，当然可以存在多个消息接收方
2、消息模式
2.1、基本队列
2.1.1、流程图
2.1.2、说明
在生产方和消息队列中，他们是有方向关系的，而对于后两者来说，没有所谓的方向关系，也就是说，谁都可
以处于主角色的定位，所以关于系统内部的消息传递会出现两种情况：
推模型
- 消息队列将消息推送给消息接收方
- 消息接收方如果消费能力不足的话，导致消息丢失。
拉模型
- 消息接收方主动从消息队列中获取数据
- 消费接收方可以根据自己的实际情况来调整消息的获取速度，但是有可能导致消息的积压问题。
2.2、发布订阅
2.2.1、流程图
2.2.2、说明
在实际的业务架构中，尤其是项目内部的功能，生产方有很多，但是消息接收方会更多，往往一个生产方会有很多消费者来进行处理，为了互相不影响彼此的功能正常进行，就出现了 发布订阅模式。
为了
防止 推模型 中的单一消息接收者的压力导致消息丢失
防止 拉模型 中的消息队列过满导致生产方无法正常推送数据
将消息队列和消息接收者之间的处理机制进行改造：
- 每个消息可以有多个订阅者；
- 针对某个消息，它必须创建一个订阅者之后，才能消费发布者的消息。
- 为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行；
2.3、消息路由
2.3.1、流程图
2.3.2、说明
无论是 基本队列模式，还是发布订阅模式，队列在其中都扮演了举足轻重的角色。然而，在企业应用系统中，当系统变得越来越复杂时，对性能的要求也会越来越高，此时对于系统而言，可能就需要支持同时部署
多个队列，并可能要求分布式部署不同的队列。
这些队列可以根据定义接收不同的消息，例如订单处理的消息，日志信息，查询任务消息等。这时，对于消息的生产者和消费者而言，并不适宜承担决定消息传递路径的职责。事实上，根据S单一职责原则，这种职
责分配也是不合理的，它既不利于业务逻辑的重用，也会造成生产者、消费者与消息队列之间的耦合，从而影响系统的扩展。
所以这时引入一个新的对象专门负责传递路径选择的功能，这就是所谓的消息路由模式
通过消息路由，我们可以配置路由规则指定消息传递的路径，以及指定具体的消费者消费对应的生产者。
例如指定路由的关键字，并由它来绑定具体的队列与指定的生产者（或消费者）。路由的支持提供了消息传递与处理的灵活性，也有利于提高整个系统的消息处理能力。同时，路由对象有效地封装了寻找与匹配消息路径的逻辑，负责协调消息、队列与路径寻址之间关系。
