项目模块划分

服务端模块：

持久化数据管理中心模块

在数据管理模块中管理交换机，队列，队列绑定，消息等部分数据数据。

\1. 交换机管理：

a. 管理信息：名称，类型，是否持久化标志，是否(无人使用时)自动删除标志，其他参数，…

b. 管理操作：恢复历史信息，声明，删除，获取，判断是否存在

\2. 队列管理：

a. 管理信息：名称，是否持久化标志，是否独有标志，是否(无人使用时)自动删除标志，其他参数，…

b. 管理操作：恢复历史信息，声明，删除，获取，判断是否存在

\3. 绑定管理：

a. 管理信息：交换机名称，队列名称，绑定主题

b. 管理操作：恢复历史信息，绑定，解绑，解除交换机关联绑定信息，解除队列关联绑定信息，获取交换机关联绑定信息

\4. 消息管理：

a. 管理信息

i. 属性：消息 ID， 路由主题，持久化模式标志

ii. 消息内容

iii. 有效标志（持久化需要）

iv. 持久化位置（内存中）

v. 持久化消息长度（内存中）

b. 管理操作：恢复历史信息，向指定队列新增消息，获取指定队列队首消息，确认移除消息

这几个核心概念数据都需要在内存和硬盘中存储的。

• 以内存存储为主，主要是保证快速查找信息进行处理

• 以硬盘存储为辅，主要是保证服务器重启之后，之前的信息都可以正常保持

虚拟机管理模块

因为交换机/队列/绑定都是基于虚拟机为单元整体进行操作的，因此虚拟机是对以上数据管理模块的整合模块。

\1. 虚拟机管理信息：

a. 交换机数据管理模块句柄

b. 队列数据管理模块句柄

c. 绑定数据管理模块句柄

d. 消息数据管理模块句柄

\2. 虚拟机对外操作：

a. 提供虚拟机内交换机声明，交换机删除操作。

b. 提供虚拟机内队列声明，队列删除操作。

c. 提供虚拟机内交换机-队列绑定，解除绑定操作。

d. 获取交换机相关绑定信息

\3. 虚拟机管理操作：

a. 创建虚拟机

b. 查询虚拟机

c. 删除虚拟机

交换路由模块

当客户端发布一条消息到交换机后，这条消息，应该被入队到该交换机绑定的哪些队列中？交换路由模块就是决定这件事情的。

在绑定信息中有一个 binding_key，而每条发布的消息中有一个 routing_key，能否入队取决于两个要素：交换机类型和 key

\1. 广播：将消息入队到该交换机的所有绑定队列中

\2. 直接：将消息入队到绑定信息中 binding_key 与消息 routing_key 一致的队列中

\3. 主题：将消息入队到绑定信息中 binding_key 与 routing_key 是匹配成功的队列中

binding_key

是由数字字母下划线构成的, 并且使用 . 分成若干部分。

例如：news.music.#，这用于表示交换机绑定的当前队列是一个用于发布音乐新闻的队列。

• 支持 * 和 # 两种通配符， 但是 * # 只能作为 . 切分出来的独立部分, 不能和其他数字字母混用,

￮ 比如 a.*.b 是合法的， a.*a.b 是不合法的

￮ * 可以匹配任意一个单词（注意是单词不是字母）

￮ # 可以匹配任意零个或者多个单词（注意是单词不是字母）

routing_key

是由数据、字母和下划线构成， 并且可以使用 . 划分成若干部分。

例如：news.music.pop，这用于表示当前发布的消息是一个流行音乐的新闻.

消费者管理模块

消费者管理是以队列为单元的，因为每个消费者都会在开始的时候订阅一个队列的消

息，当队列中有消息后，会将队列消息轮询推送给订阅了该队列的消费者。

因此操作流程通常是，从队列关联的消息管理中取出消息，从队列关联的消费者中取

出一个消费者，然后将消息推送给消费者（这就是发布订阅中负载均衡的用法）。

\1. 消费者信息：

a. 标识

b. 订阅队列名称

c. 自动应答标志（决定了一条消息推送给消费者后，是否需要等待收到确认后

再删除消息）

d. 消息处理回调函数指针（一个消息发布后调用回调，选择消费者进行推送…）

i. void(const std::string& tag, const BasicProperties& p,

const std::string& body)

\2. 消费者管理：添加，删除，轮询获取指定队列的消费者，移除队列所有消费者等

操作

信道管理模块

本质上，在 AMQP 模型中，除了通信连接 Connection 概念外，还有一个 Channel 的

概念，Channel 是针对 Connection 连接的一个更细粒度的通信信道，多个 Channel 可

以使用同一个通信连接 Connection 进行通信，但是同一个 Connection 的 Channel 之

间相互独立。

而信道模块就是再次将上述模块进行整合提供服务的模块

\1. 管理信息：

a. 信道 ID

b. 信道关联的消费者

c. 信道关联的连接d. 信道关联的虚拟机

e. 工作线程池（一条消息被发布到队列后，需要将消息推送给订阅了对应队列

的消费者，过程由线程池完成）

\2. 管理操作：

a. 提供声明&删除交换机操作（删除交换机的同时删除交换机关联的绑定信息）

b. 提供声明&删除队列操作（删除队列的同时，删除队列关联的绑定信息，消息，

消费者信息）

c. 提供绑定&解绑队列操作

d. 提供订阅&取消订阅队列消息操作

e. 提供发布&确认消息操作

连接管理模块

本质上，咱们仿照实现的服务器是通过 muduo 库来实现底层通信的，而这里的连接管理，更多的是对 muduo 库中的 Connection 进行二次封装管理，并额外提供项目所需操作。

\1. 管理信息：

a. 连接关联的信道

b. 连接关联的 muduo 库 Connection

\2. 管理操作：新增连接，删除连接，获取连接，打开信道，关闭信道。

Broker 服务器模块

整合以上所有模块，并搭建网络通信服务器，实现与客户端网络通信，能够识别客户端请求，并提供客户端请求的处理服务。

管理信息：

a. 虚拟机管理模块句柄

b. 消费者管理模块句柄

c. 连接管理模块句柄

d. 工作线程池句柄

e. muduo 库通信所需元素…

客户端模块：

消费者管理

消费者在客户端的存在感比较低，因为在用户的使用角度中，只要创建一个信道后，

就可以通过信道完成所有的操作，因此对于消费者的感官更多是在订阅的时候传入了

一个消费者标识，且当前的简单实现也仅仅是一个信道只能创建订阅一个队列，也就

是只能创建一个消费者，它们一一对应，因此更是弱化了消费者的存在。

\1. 消费者信息：

a. 标识

b. 订阅队列名称

c. 自动应答标志（决定了一条消息推送给消费者后，是否需要等待收到确认后

再删除消息）

d. 消息处理回调函数指针（一个消息发布后调用回调，选择消费者进行推送…）

\2. 消费者管理：添加，删除，轮询获取指定队列的消费者，移除队列所有消费者等

操作

信道请求模块

与服务端的信道类似，客户端这边在 AMQP 模型中，也是除了通信连接 Connection

概念外，还有一个 Channel 的概念，Channel 是针对 Connection 连接的一个更细粒度

的通信信道，多个 Channel 可以使用同一个通信连接 Connection 进行通信，但是同一

个 Connection 的 Channel 之间相互独立。

\1. 信道管理信息：

a. 信道 ID

b. 信道关联的通信连接

c. 信道关联的消费者

d. 请求对应的响应信息队列（这里队列使用 hash 表，以便于查找指定的响应）

e. 互斥锁&条件变量（大部分的请求都是阻塞操作，发送请求后需要等到响应才

能继续，但是 muduo 库的通信是异步的，因此需要我们自己在收到响应后，通过

判断是否是等待的指定响应来进行同步）

\2. 信道管理操作：

a. 提供创建信道操作

b. 提供删除信道操作

c. 提供声明交换机操作（强断言-有则 OK，没有则创建）

d. 提供删除交换机e. 提供创建队列操作（强断言-有则 OK，没有则创建）

f. 提供删除队列操作

g. 提供交换机-队列绑定操作

h. 提供交换机-队列解除绑定操作

i. 提供添加订阅操作

j. 提供取消订阅操作

k. 提供发布消息操作

通信连接模块

向用户提供一个用于实现网络通信的 Connection 对象，从其内部可创建出粒度更轻的

Channel 对象，用于与服务端进行网络通信。

\1. 管理信息：

a. 连接关联的实际用于通信的 muduo::net::Connection 连接

b. 连接关联的信管理句柄（实现信道的增删查）

c. 连接关联的 EventLoop 异步循环工作线程

d. 异步工作线程池（用于对收到服务器推送过来的消息进行处理的线程池）

\2. 管理操作：

a. 提供创建 Channel 信道的操作

b. 提供删除 Channel 信道的操作