百日筑基第二十天-一头扎进消息队列3-RabbitMQ

百日筑基第二十天-一头扎进消息队列3-RabbitMQ

如上图所示，RabbitMQ 由 Producer、Broker、Consumer 三个大模块组成。生产者将数据发送到 Broker，Broker 接收到数据后，将数据存储到对应的 Queue 里面，消费者从不同的 Queue 消费数据。

那么除了 Producer、Broker、Queue、Consumer、ACK 这几个消息队列的基本概念外，它还有 Exchange、Bind、Route 这几个独有的概念。

Exchange 称为交换器，它是一个逻辑上的概念，用来做分发，本身不存储数据。流程上生产 者先将消息发送到 Exchange，而不是发送到数据的实际存储单元 Queue 里面。然后 Exchange 会根据一定的规则将数据分发到实际的 Queue 里面存储。这个分发过程就是 Route （路由），设置路由规则的过程就是 Bind（绑定）。即 Exchange 会接收客户端发送 过来的 route_key，然后根据不同的路由规则，将数据发送到不同的 Queue 里面。

这里需要注意的是，在 RabbitMQ 中是没有 Topic 这个用来组织分区的逻辑概念的。 RabbitMQ 中的 Topic 是指 Topic 路由模式，是一种路由模式，和消息队列中的 Topic 意义 是完全不同的。

协议和网络模块

RabbitMQ 在协议内容和连接管理方面，都是遵循 AMQP 规范。即 RabbitMQ 的模型架构 和 AMQP 的模型架构是一样的，交换器、交换器类型、队列、绑定、路由键等都是遵循 AMQP 协议中相应的概念。

RabbitMQ 的网络层有 Connectoion 和 Channel 两个概念。

Connection 是指 TCP 连接，Channel 是 Connection 中的虚拟连接。两者的关系是：一个 客户端和一个 Broker 之间只会建立一条 TCP 连接，就是指 Connection。Channel（虚拟连 接）的概念在这个连接中定义，一个 Connection 中可以创建多个 Channel。

客户端和服务端的实际通信都是在 Channel 维度通信的。这个机制可以减少实际的 TCP 连接 数量，从而降低网络模块的损耗。从设计角度看，也是基于 IO 复用、异步 I/O 的思路来设计 的。

数据存储

RabbitMQ 的存储模块也包含元数据存储与消息数据存储两部分，两类数据都是存储在 Broker 节点上的，不会依赖第三方存储引擎。

RabbitMQ 的元数据都是存在于 Erlang 自带的分布式数据库 Mnesia 中的。即每台 Broker 都会起一个 Mnesia 进程，用来保存一份完整的元数据信息。因为 Mnesia 本身是一个分布式 的数据库，自带了多节点的 Mnesia 数据库之间的同步机制。所以在元数据的存储模块， RabbitMQ 的 Broker 只需要调用本地的 Mnesia 接口保存、变更数据即可。不同节点的元数 据同步 Mnesia 会自动完成。Mnesia 对 RabbitMQ 的作用，相当于 ZooKeeper 对于 Kafka、NameServer 对于 RocketMQ 的作用。因为 Mnesia 是内置在 Broker 中，所以部署 RabbitMQ 集群时，你会 发现只需要部署 Broker，不需要部署其他的组件。这种部署结构就很简单清晰，从而也降低 了后续的运维运营成本。

RabbitMQ 消息数据的最小存储单元是 Queue，即消息数据是按顺序写入存储 到 Queue 里面的。在底层的数据存储方面，所有的 Queue 数据是存储在同一个"文件"里 面的。这个"文件"是一个虚拟的概念，表示所有的 Queue 数据是存储在一起的意思。

RabbitMQ 也提供了过期时间（TTL）机制，用来删除集群中没用的消息。它支持单条消息和 队列两个维度来设置数据过期时间。如果在队列上设置 TTL，那么队列中的所有消息都有相同 的过期时间。我们也可以对单条消息单独设置 TTL，每条消息的 TTL 可以不同。如果两种方 案一起使用，那么消息的 TTL 就会以两个值中最小的那个为准。如果不设置 TTL，则表示此 消息不会过期。

生产者和消费者

当生产者和消费者连接到 Broker 进行生产消费的时候，是直接和 Broker 交互的，不需要客 户端寻址。客户端连接 Broker 的方式，跟我们通过 HTTP 服务访问 Server 是一样的，都是直连的。

在消费端，RabbitMQ 支持 Push（推）和 Pull（拉）两种模式，如果使用了 Push 模式， Broker 会不断地推送消息给消费者。不需要客户端主动来拉，只要服务端有消息就会将数据 推给客户端。当然推送消息的个数会受到 channel.basicQos 的限制，不能无限推送，在消费 端会设置一个缓冲区来缓冲这些消息。拉模式是指客户端不断地去服务端拉取消息， RabbitMQ 的拉模式只支持拉取单条消息。

为了保证消费流程的可靠性，RabbitMQ 也提供了消息确认机制。消费者在消费到数据的时 候，会调用 ACK 接口来确认数据是否被成功消费。

总结

RabbitMQ 主要有 Producer、Broker、Consumer、Exchange、Queue、Route、Bind、 Connection、Channel、ACK 等概念。

总结 RabbitMQ，可以从以下七个方面入手：

思考题 请你按照基础篇的课程思路，完整描述一下 RabbitMQ 从生产到消费的全过程？

1. 协议层基于 AMQP 标准开发。
2. 网络层核心数据流基于 TCP 协议通信，并通过 Connection 和 Channel 机制实现连接的复 用，以减少创建的 TCP 连接数量。
3. 存储层基于多个 Queue 数据统一到一个文件存储的思路设计，同时支持分段存储和基于时 间的数据过期机制。
4. 元数据存储是基于 Erlang 内置的数据库 Mnesia 来实现。
5. 客户端的访问是直连的，没有客户端寻址机制。
6. 生产端是通过 Exchange 和 Route 写入数据的，生产数据的分发是在服务端完成的，其他消息队列的分发一般都是在客户端。
7. 消费端没有消费分组、消费分区分配等概念，直连 Queue 消费，同时也提供了手动和自动 两种 ACK 机制。