（四）RabbitMQ基础知识

目录

1.一些基础概念

2.rabbitmq好处

3.应用场景

4.交换机类型

5.消息基于什么进行传输

6.如何确保消息正确的发送

7.如何确保接收方消费了消息

8.如何避免消息重复投递和重复消费

9.如何确保数据不被丢失

10.消息队列的缺点

---

1.一些基础概念

AMQP 
AMQP（高级消息队列协议）是一个网络协议，它支持符合要求的客户端应用（application）和消息中间件代理（messaging middleware broker）之间进行通信。
简单的来说，可以看做一个 MQ 规范，而 RabbitMQ 是基于这一规范来实现的，实际上，它定义了基础概念和一些必要的接口的实现必要条件（可以看作是抽象类）。关于 RabbitMQ 中的所有概念，你都能在 AMQP 中找到对应的介绍。

Broker
Broker 是消息服务中间件中的一个服务节点，大部分情况下可以把 一个 Broker 看成一个 RabbitMQ 的服务器——

从这张图中可以看出 Broker 相当于一个消息服务的中央节点，而我们的消息队列核心功能也就在 Broker 上

队列
消息都存储在队列中，下图是一个简单的模型，实际上，我们也可以手写一个消息队列服务，只要有生产者、消费者和存储单元组成队列就行了：

Exchange
交换机（Exchange）在 RabbitMQ 中是一个非常重要的概念，承担了一些队列的逻辑处理功能——默认来说，对于生产者，我只知道把产生的内容丢到 MQ 当中，但是发到哪个队列中，这一点对生产者来说是无感知的，也不知道目前队列的状况如何，而 Exchange 就承担了「发到哪个队列中」的职责，用几种路由策略来决定如果分发给不同的队列。

Connection 和 Channel
每一个 Connection 是一条 TCP 连接，理论上而言每一个生产者和消费者都需要一条 Connection，但是 TCP 连接的开销会很大，因此我们会使用 Channel 来进行 TCP 复用，减少性能的开销。

Exchange 类型
熟悉了一些基本概念之后，我们大致知道了 RabbitMQ 的运作流程和连接时的一些参数，接下来开始介绍 Exchange 的类型，帮助我们更好地理解 Exchange 这个概念。

fanout
我们比较常用的一种 Exchange 类型，它会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。

direct
把消息路由到 binding key 和 routing key 完全匹配的队列中。

binding key 和 routing key 基本上可以理解为一个对 Queue 的称呼。

图中 Queue1 叫 warning，Queue2 可以叫 info，warning 或者 debug，那样 Exchange 叫了声 warning 的时候就会有两个 Queue 过来，拿到数据，而 info 则只有 Queue2 会回应。

topic
direct 类型太过严格，大部分时间我们都用不上这么严格的规则，因此有了 topic。

topic 可以看做是一种正则表达式规则，满足正则表达式的规则就会进入队列。

headers
这种类型根据发送消息中的 header 来匹配，性能差，基本没用。

死信队列
介绍完了基础概念，接下来就要说一些常用的知识了，第一个就是死信队列：

如果开启死信队列，那么当以下问题产生的时候：

1. 消息被拒绝（basic.reject/ basic.nack）并且不再重新投递 requeue=false
2. 消息超期 (rabbitmq Time-To-Live -> messageProperties.setExpiration())
3. 队列超载

导致队列无法处理的时候，有一个兜底策略，使得消息不会被堆积在队列里，而换到死信队列被消费。

在 RabbitMQ 中开启死信队列非常简单，只要配置为 DLX 即可。

共用 Connection 而不是 Channel
共用 Connection 的理由在上文已经说过了，那么为什么我们不建议共用 Channel 呢？

实际上大家都知道，计算机网络传输信息的时候，本质上都是二进制传输，而传输的数据经过一定的处理，最终变成了我们可读可处理的数据，Channel 已经是复用了 TCP 连接的，此时如果我们再进行并行的数据传输，很有可能会导致某一帧数据的异常。在使用的过程中，由于我们的程序复用了 Channel 同时提供给生产者和消费者，也确实遇到了这样的问题。
 

2.rabbitmq好处

1. 流量削峰：避免大流量时，所有请求都同时操作数据库。数据库io是十分消耗资源的。
2. 应用解耦：应用a需要对应用b进行操作，例如订单的下单后的减库存操作。库存应用宕机后，避免因为库存应用的宕机，而导致操作报错。
3. 异步处理：避免串行操作，例如某个操作需要发送系统消息和发送短信的操作不应该串行，而是同时进行，加快响应。

3.应用场景

1.简单队列：
一个生产者------消息队列-----一个消费者

2.工作队列：
一个生产者-----消息队列------多个消费者
轮询：按照消息的先后依次分发给消费者
公平分发：不会平均分发，而是谁有空就谁消费

3.发布者订阅模式：
一个生产者---交换机----多个队列----队列对应的消费者
交换机没有存储数据的能力，队列才有，所以交换机需要绑定队列，交换机接收到生产者的数据，推送给队列。

4.topic主题模式：
主要交换机有路由键的存在，将路由键和队列进行绑定，发送消息时，指定路由键的内容，发送给绑定的队列即可。

4.交换机类型

1. fanout:当有消息时，把消息发送给所有队列。
2. topic:有路由键，将路由键和队列进行绑定。
3. direct和header：这两个不常用。

5.消息基于什么进行传输

由于tcp创建和销毁开销大，所以消息一般基于信道传输。
信道是基于tcp连接的虚拟连接，一个tcp连接可以包含很多个信道。

6.如何确保消息正确的发送

rabbitmq采用发送方确认的模式，确保消息正确的发送到rabbitmq。
发送方确认模式：一旦消息到达队列后，会给发送方一个确认的信息。而rabbitmq内部错误没有接收到时，会给发送发一个未确认的信息。

7.如何确保接收方消费了消息

rabbitmq采用接收方确认模式。 
每一条消息都会被接收方确认，一旦确认消费了消息，rabbitmq才会将消息从队列中删除。

8.如何避免消息重复投递和重复消费

生产者每发送一条消息都会生产一个内部消息id，防止重复投递。 
当消费者消费时，每条消费的信息都有一个全局id，防止被重复消费。

9.如何确保数据不被丢失

生产者不丢失数据： 
rabbitmq采用transaction和confirm来确保消息不被丢失。 

消息队列不丢失数据： 
一般采用持久化磁盘的操作。 

消费者不丢失数据： 
采用消费确认模式。

10.消息队列的缺点

系统复杂性增加

【相关链接】

（一）CentOS7安装RabbitMQ  https://blog.csdn.net/weixin_37689230/article/details/112276503
（二）laravel整合rabbitmq消息队列  https://blog.csdn.net/weixin_37689230/article/details/112321216
（三）Horizon 队列管理工具  https://blog.csdn.net/weixin_37689230/article/details/112366571
（四）RabbitMQ基础知识  https://blog.csdn.net/weixin_37689230/article/details/112542844