前言

本文是游戏业务线消息队列中间件详细架构设计文档，用于指导消息队列后续的开发、测试和运维等相关工作

词汇表

Reactor: 网络编程模式

Netty: 开源的网络编程框架

Zookeeper：的分布式应用程序协调服务

Mysql：关系型数据库管理系统

QPS：每秒查询率

TP99：满足百分之九十九的网络请求所需要的最低耗时

Topic(主题):每条消息都有一个类别，这个类别称为 topic

Producer(生产者)：负责发送指定 topic 的消息到业务服务器

Consumer(消费者):消息读取客户端，指定 topic 来消费消息

1. 业务背景

随着游戏业务的快速发展，系统也越来越多，系统间协作需求越来越复杂，由此带来几个明显的系统问题：

效率问题：一个消息传递要经过多个系统的多轮处理才完成他的使命，目前直接系统间调用间接增加了系统的负担以及系统内的业务复杂度；

数据规范问题：目前系统传递消息都是点对点的数据约束，无法作为一个统一的可以复用的消息进行传播；

耦合问题：当新增一个运营需要对接相关的论坛、包管理、APP、WEB 等系统；

基于以上背景，我们需要引入消息队列进行系统解耦，提高多系统间交互效率，统一消息传输数据格式。

新系统架构

2. 约束和限制

1、必须在 2021 年 Q3 结束前完成

2、成本不超过 1000W

3、数据库采用 Mysql

4、交付性能 QPS 不低于 4000，数据延迟 TP99 不低于 200ms，可用性不低于 99.9%

5、实施过程不能和主版本需求冲突

6、如遇运营需求与本项目交付时间冲突，实行优先上线再进行改造

7、自 2021.5.10 起，所有相关系统交互消息格式需要遵循本文档数据规范进行设计和实施

3. 总体架构

使用 Mysql 实现消息队列，并实现数据分组，读写分离，主备容灾等功能。

3.1 架构分析

3.1.1 高可用

由于本消息系统将应用于版本发布、充值等业务优先级较高的场景，所以对高可用要求较高。

计算高可用：

分配算法：轮询

配置获取：zookeeper

运行形态：SDK|服务器（http 接口）

存储高可用：采用 Mysql 的主从机制，以及其自身的意外数据恢复能力保证

3.2 总体架构

1）采用数据分散集群的架构，集群中的服务器进行分组，每个分组存储一部分消息数据。

2）每个分组包含一台主 MySQL 和一台备 MySQL，分组内主备数据复制，分间数据不同步。

3）正常情况下，分组内的主服务器对外提供消息写入和消息读取服务，备服务器不对外提供服务；主服务

4）器宕机的情况下，备服务器对外提供消息读取的服务。

5）客户端采取轮询的策略写入和读取消息。

6）客户端支持 SDK 和 HTTP 接口两种调用方式。

4. 详细设计

4.1 核心功能

4.1.1 消息发送流程

1）、生产者通过配置的业务服务器集群进行轮询业务写入申请操作；

2）、业务服务受到请求之后去配置中心(zookeeper)获取数据分组信息；

3）、配置中心返回数据分组信息；

4）、根据数据分组信息，进行数据写入，如果没有分组配置，默认写入数据分组 1 中；

5）、数据主从同步；

6）、业务服务返回处理结果；

4.1.2 消息消费流程

1）、消费者申请进行消息消费；

2）、业务服务器去配置中心(zookeeper)获取消费者 offset，以及消费者对应的存储分组；

3）、业务服务器读取消息；

4）、业务服务器发送消息；

5）、业务服务器如果发送成功，更新对应 offset 信息到 zookeeper

4.2 关键设计

4.2.1 消息发送可靠性

业务服务器中嵌入消息队列系统提供的 SDK，SDK 支持轮询发送消息，当某个分组的主服务器无法发送消息时，SDK 挑选下一个分组主服务器重发消息，依次尝试所有主服务器直到发送成功；如果全部主服务器都无法发送，SDK 可以缓存消息，也可以直接丢弃消息，具体策略可以在启动 SDK 的时候通过配置指定。

如果 SDK 缓存了一些消息未发送，此时恰好业务服务器又重启，则所有缓存的消息将永久丢失，这种情况 SDK 不做处理，业务方需要针对某些非常关键的消息自己实现永久存储的功能。

4.2.2 消息存储可靠性

消息存储在 MySQL 中，每个分组有一主一备两台 MySQL 服务器，MySQL 服务器之间复制消息以保证消息存储高可用。如果主备间出现复制延迟，恰好此时 MySQL 主服务器宕机导致数据无法恢复，则部分消息会永久丢失，这种情况不做针对性设计，DBA 需要对主备间的复制延迟进行监控，当复制延迟超过 30 秒的时候需要及时告警并进行处理。

4.2.2 消息存储格式

每个消息队列对应一个 MySQL 表，消息队列名就是表名，表结构设计如下

4.3 设计规范

1）消息队列服务器使用 Spring Boot + Netty 开发

2）MySQL 使用 Innodb 存储引擎

3）TCP 包的结构设计如下：

生产者请求包：

生产者响应包：

消费者请求包：

消费者响应包：

5. 质量设计

5.1 消息队列管理后台

一、对消息队列的整体负载情况进行监控、查看

二、对消息队列的配置信息进行监控和维护

5.2 成本

一、开发成本，整体开发人员对 Springboot、Netty、MySQL、ZooKeeper 等技术栈掌握较为熟练，可以保证交付日期与质量；

二、硬件投入：前期可以只投入较少资源进行试运行，业务成熟之后可以快速扩容，扩容对开发无影响，对运维影响也不是很大；

三、其他成本：整体架构全都采用免费或者开源方案，不会产生其他成本费用。

5.3 可测试性

支持 HTTP 接口，方便测试人员使用主流测试工具进行快速测试，无编程语言门槛。

5.4 可观测性

消息队列管理后台提供了对应的观测性保障。

5.5 安全性

本项目为公司内部使用，全链路采用内网方式，无需考虑安全性

6. 演进规划

6.1 消息队列一期

完成核心设计功能，支持 SDK 调用

6.2 任务消息队列二期

1、支持 http 接口

2、完成管理后台

3、优化任务分配机制算法等内容