浅谈RabbitMQ

浅谈RabbitMQ

什么是消息中间件？

    消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行 分布式系统 的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信

消息中间件引出产生背景

一、系统之间接口耦合比较严重
系统之间直接调用实际工程落地和存在问题
    微服务架构后，链式调用是我们在写程序时候的一般流程，为了完成一个整体功能会将其拆分成多个函数（或子模块），比如模块 A 调用模块 B，模块 B 调用模块 C，模块 C 调用模块 D。但在大型分布式应用中，系统间的 RPC 交互繁杂，一个功能背后要调用上百个接口并非不可能，从单机架构过渡到分布式服务架构的通例，这种架构会有哪些问题？

系统之间接口耦合比较严重
每新增一个下游功能，都要对上有相关接口进行改造；

举个例子：假如系统 A 要发送数据给系统 B 和 C，发送给每个系统的数据可能有差异，因此系统 A 对要发送给每个系统的数据进行了组装，然后逐一发送；

当代码上线后又新增了一个需求：

把数据也发送给 D，新上了一个 D 系统也要接受 A 系统的数据，此时需要修改 A 系统，让它感知到 D 的存在，同时把数据处理好 A 再给 D。在这个过程中你会发现，每接入一个下游系统，都要对 A 系统进行代码改造，开发联调的效率很低。其整体架构如下图

二、面对大流量并发时，容易被冲垮

每个接口模块的吞吐量能力是有限的，这个上限能力如果堤坝，当大流量（洪水）来临时，容易被冲垮

举个例子秒杀业务：

上游系统发起下单购买 *** 作，就是下单一个 *** 作

下游系统完成秒杀业务逻辑
（读取订单、库存检查、库存冻结、余额检查、余额冻结、订单生成、余额扣减、库存扣减、生成流水、余额解冻、库存解冻）

三、等待同步存在性能问题

RPC 接口基本上是 同步调用，整体服务性能遵循 “木桶理论”，即 整体系统的耗时取决于链路中 最慢的 那个接口

比如 A 调用 B/C/D 都是 50ms，但此时 B 又调用了 B1，花费 2000 ms，那么直接就拖累了整个服务性能

如何解决？
要做到系统解耦，当新的模块接进来时，可以做到代码改动最小；能够解耦
设置流量缓冲池，可以让后端系统按照自身吞吐能力进行消费，不被冲垮；能够削峰
强弱依赖梳理能将非关键调用链路的 *** 作异步化并提升整体系统的吞吐能力；能够异步
消息中间件的定义
面向消息的中间件（Message-Oriented Middleware）MOM 能够很好的解决以上问题

    是指利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供 消息传递 和 消息排队 模型在分布式环境下提供应用解耦、d性伸缩、冗余存储、流量削峰、异步通信、数据同步等功能

大致的过程是这样的：

    发送者把消息发送给消息服务器，消息服务器将消息存放在若干个 队列 / 主题 中，在合适的时候，消息服务器会将消息转发给接收者。在这个过程中，发送和接收是异步的，也就是发送无需等待，而且发送者和接收者的生命周期也没有必然关系；尤其在发布 pub / 订阅 sub 模式下，也可以完成一对多的通信，即让一个消息有多个接收者

特点
采用异步处理模式
    消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一条虚拟的通道（主题或队列上）；消息接收者则订阅或监听该通道。一条信息可能最终转发给一个或者多个消息接收者，这些接收者都无需对消息发送者做出同步回应，整个过程都是异步的

案例：
    也就是说，一个系统跟另一个系统之间进行通信的时候，假如系统 A 希望发送一个消息给系统 B，让它去处理
    但是系统 A 不关注系统 B 到底怎么处理或者有没有处理好，所以系统 A 把消息发送给 MQ，然后就不管这条消息了，接着系统 B 从 MQ 里消费出来处理即可。至于怎么处理，是否处理完毕，什么时候处理，都是系统 B 的事，与系统 A 无关

这样的一种通信方式，就是所谓的 “异步” 通信方式对于系统 A 来说，只要把消息发送给 MQ，然后系统 B 就会异步的去进行处理了，系统 A 不需要 “同步” 的等待系统 B 处理完。这样的好处是什么呢？两个字：解耦

应用场景
1、任务异步处理

将不需要同步处理的并且耗时长的 *** 作由队列通知消息接收方进行异步处理，提高了应用程序的响应时间
2、应用程序解耦合

MQ 相当于一个中介，生产方通过 MQ 与消费方进行交互，它将应用程序进行解耦合
市场上还有哪些 MQ？
ActiveMQ、RabbitMQ、ZeroMQ、Kafka、metaMQ、RocketMQ、Redis

为什么使用 RabbitMQ？
使用简单，功能强大
基于 AMQP 协议
社区活跃，文档完善
高并发性能好，这主要得益于 Erlang 语言
SpringBoot 默认已集成 RabbitMQ
RabbitMQ 的工作原理

组成部分说明如下：
Broker：消息队列服务进程，此进程包括两个部分：Exchange 和 Queue
Exchange：消息队列交换机，按一定的规则将消息路由转发到某个队列，对消息进行过滤
Queue：消息队列，存储消息的队列，消息到达队列并转发给指定的消费方
Producer：消息生产者，即生产方客户端，生产方客户端将消费发送到 MQ
Consumer：消息消费者，即消费方客户端，接收 MQ 妆发的消息

消息发布接收流程
发送消息
1、生产者和 Broker 建立 TCP 连接
2、生产者和 Broker 建立通道
3、生产者通过通道消息发送 Broker，由 Exchange 将消息进行转发
4、Exchange 将消息转发到指定的 Queue（队列）
接收消息
1、消费者和 Broker 建立 TCP 连接
2、消费者和 Broker 建立通道
3、消费者监听指定的 Queue（队列）
4、当有消息到达 Queue 时 Broker 默认将消息推送给消费者
5、消费者接收到消息