【RabbitMQ 项目】项目概述
项目概述
- 一.角色划分
- 二.服务器模块概述
- 1.本地模块
- 2.网络模块
- 3.服务器模块
- 三.模块详细划分
- 1.服务端
- 2.客户端
一.角色划分
该项目的模型是一个跨主机的生产消费模型,有三种角色:生产者,消费者,中间人。对应就要实现三个大模块:服务端,消息生产客户端,消息消费客户端。服务端要完成一个消息队列服务器模块,这个模块是整个项目的核心
二.服务器模块概述
服务器模块又可以划分成三个模块:
- 本地模块:服务器的核心模块,也可以叫业务模块,对本地消息的增删查,完全自主实现
- 协议模块:数据序列化和反序列化,报文封装与解包。使用 Protobuf 完成前者,使用 muduo 库实例代码中提供的自定义协议完成后者
- 网络模块:字节流接受和发送,以及连接管理。前者由 muduo 库完成,后者自己封装实现
1.本地模块
核心概念:
- 虚拟机:虚拟机是逻辑上的概念,就好比 MySQL 中的数据库,一台 MySQL 服务器上可以有多个数据库,那么一台消息队列服务器上也可以有多台虚拟机。虚拟机是一个逻辑上的集合,里面有很多对象,有哪些呢?有以下这些:
- 消息队列:一个虚拟机中可以有很多不同类型的消息队列,用来存储不同类型的消息
- 交换机:生产者的目的是要将消息发布到指服务器的消息队列中,但有时候想要把一条消息发布到多个队列,比如我现在有一份素材,想要交给消息队列服务器,推送给消费者,去加工素材形成新闻。服务器上有很多类型的队列,比如和音乐素材队列,体育素材队列,我的素材是某体育明星创作了一首歌曲,我想要同时发布到音乐和体育队列,那么我就就要去发布两次,比较繁琐。所以引出了交换机的概念,我不会直接把把消息给消息队列,而是先给交换机,让交换机使用交换路由算法,把消息发布到音乐和体育素材队列中去。
- 绑定:交换机要把消息发送到队列,那么一定要和队列建立联系,Binding 对象就代表它们之间的关联关系。Binding 和交换机的交换路由算法有关,这里不展开谈
- 消息:要传递的内容,需要持久化,除了消息,上述的对象都需要持久化,只不过消息直接写到文件,其它对象用的是 sqlite 数据库
核心接口:
该项目简是了 RabbitMQ 的简化版,服务器上只有一台虚拟机,所以本地模块的核心接口就是虚拟机的核心接口,有如下这些:
- 交换机,消息队列,绑定的创建与销毁
- 发布消息
- 订阅队列和取消订阅
- 确认消息:消息发送给消费者后暂时不会删除,直到消费者手动调用应答的接口,发送应答请求,服务器收到后,调用确认应答的接口,把消息删除
2.网络模块
网络模块主要是进行网络 IO,除此之外,还要还要管理 Connection 和 Channel
核心概念:
Connection 和 Channel:Connection 对应一个 TCP 连接,Channel 是一个逻辑上的信道,一个 Connection 可以包含多个 Channel,Channel 之间数据是独立的。服务器和客户端建立的连接,不是一个个 Connection,而是逻辑上的 Channel,当然 Channel 本质上还是使用 Connection 通信。
为什么要把 Connection 细分:达到长连接的效果,更好地复用 TCP 连接,避免频繁创建和关闭 TCP 连接。我们使用的是 muduo 库来搭建服务器,所以 IO 相关的接口就不用自己实现了,我们要实现的是:
- Connection,Channel 的连接和关闭
网络模块
3.服务器模块
核心接口:
- Connection,Channel 的连接和关闭
- 交换机,队列,绑定的创建和销毁
- 发布消息
- 订阅队列和取消订阅
- 确认消息
你会发现,服务器提供的几个接口,本地模块,网络模块不是也有吗?实际上,这几个接口实现就是使用的是网络模块和本地模块,这就是分层设计的思想。
网络模块,协议模块和本地模块怎么关联起来的呢?muduo 库中的回调机制:TCP 连接建立成功了,回调,创建 Connection,创建信道;TCP 连接关闭,回调,销毁 Connection,销毁信道;缓冲区中的数据读取上来了,回调,去用协议处理器解析字节流,得到结构化的请求,再分发给相应的业务回调函数,业务回调函数中,做增删查,然后构建响应报文,给客户端返回过去
三.模块详细划分
1.服务端
本地模块:
- 数据管理模块
准确的说是虚拟机数据管理模块,因为一台服务器上只有一个虚拟机。包含以下子模块:
- 交换机管理模块
- 队列管理模块
- 绑定管理模块
- 消息管理模块
以上的四种数据都要持久化管理,所以数据管理包含内存和磁盘两方面管理- 路由交换模块
生产者把消息发布给交换机,交换机决定放入哪些队列,这个决定就由路由交换模块提供的算法来完成。路由交换算法,要结合交换机的类型,以及消息中的 routing key,绑定中的 binding key 做规则匹配- 消费者管理模块
这里的消费者是指订阅了某个消息队列的对象,一个用户可能通过消费客户端订阅了多个队列,所以虽然这些订阅都来自同一客户端,但在我服务端看来,有多个消费者。服务端为什么要管理消费者?是因为当有消息发布到队列中,就需要推送给订阅该队列消息的客户端,所以要把消费者管理起来网络模块:
- 信道管理模块
信道是比连接粒度更细的通信通道,一个连接中有一个或多个信道,客户端关闭通信,关闭的是信道而不是连接,信道关闭后,就要把客户端的一个或多个订阅取消- 连接管理模块
Connection 是对 muduo 库中 TcpConnectionPtr 的封装,而后者是对套接字的封装,所以一个 Connection 对应一个 TCP 连接。当连接关闭后,与之关联的信道也要随之关闭。服务器模块:
- 服务器模块
对以上所有模块的整合,并且还使用了 muduo 库,Protobuf,应用层协议等,搭建的一个高并发服务器
2.客户端
- 消费者管理模块——消息订阅客户端才会用到
- 信道管理模块
- 连接管理模块
基于以上三个模块,就可以分别实现发布客户端和订阅客户端