前言

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

词汇表

Netty：稳定的开源网络编程框架

Reactor：高效的网络编程模式

MongoDB Sharded Cluster：MongoDB 存储的高性能、高可用架构模式

ZooKeeper：开放源码的分布式应用程序协调服务

1. 业务背景

2014 年左右，游戏业务发展很快，系统也越来越多，系统间协作的效率很低，例如：

【新版本发布了】

1. 游戏厂家更新游戏版本后，运营人员获取最新的游戏包，更新版本信息，然后上传包

到包管理系统打测试包，运营人员进行基本测试。运营子系统通知论坛有新的包将要

发布，进行预热。

2. 测试完成后，运营管理子系统要通知包管理系统进行打包

3. 游戏准点正式发布的时候，运营子系统要通知 App、Web 站点等即时更新到新版本

【玩家充钱了】

1. 玩家进行充值，充值完成后充值子系统通知 VIP 子系统；

2. VIP 子系统判断玩家等级，达到 VIP 后，等级子系统要通知福利子系统进行奖品发

放，要通知客服子系统安排专属服务人员，要通知商品子系统进行商品打折处理……

等级子系统的开发人员也是不胜其烦。

从当前业务描述可以看出的问题：

1. 各系统业务严重耦合。

2. VIP 子系统业务效率低。

2. 约束和限制

1. 游戏业务讲求实时性和有效性，必须保证队列的高可用。

2. 成本不能太高。

3. 各种维护操作要方便，例如收发消息情况、权限控制、上下线，希望队列可维护性高。

3. 总体架构

3.1 架构图概览

3.2 架构分析

3.2.1 高可用

尊贵的 VIP 客户充值后就希望正常开通对应的功能，所以队列服务要保证提交过来的数据在正常消费之前不能丢失，保证 VIP 客户的体验。

3.2.2 高性能

虽然使用 VIP 充值服务的玩家在游戏玩家中占比中只是小数，但是面对未来增加的玩家基数，需要结合业务进行估算，可以容纳一定量的并发数。

3.2.3 可扩展

可考虑队列服务上的一些维护功能。

3.2.4 成本

因为实际能投入人员只有 6 人，整个设计开发必须控制在 6 人可承受开发量范围内。

3.3 总体架构

1）消息队列系统自身基于 ZooKeeper 实现服务集群。

2）MySQL 实现类似于 MongoDB Sharded Cluster 的数据分组。

3）各分片数据不同步，每个分片使用主备模式，正常情况下主通过主数据服务进行读写，当主数据服务宕机时备服务才对外提供临数据读取。

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

4. 详细设计

4.1 核心功能

4.1.1 消息发布流程

4.1.2 消息 PUSH 消费流程

4.1.3 消息 PULL 消费流程

4.1.3 消息配置加载

4.2 关键设计

1）消息发送可靠性

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

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

2）消息存储可靠性

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

3）消息如何存储

CREATE TABLE `消息队列名` (

`id` int NOT NULL COMMENT '消息 id',

`value` varchar(1000) DEFAULT NULL COMMENT '消息信息',

`isConsume` tinyint DEFAULT 0 NOT NULL COMMENT '是否被消费(日后功能扩展用) 0 未消费 1 已消费'

)

4）消息及时性

当消息系统接收到信息后主动向配有对应消费队列名的客户端进行 push 消息推送。

5）服务系统高可用

利用 ZooKeeper 的选举算法，实现服务系统的高可用。

4.3 设计规范

• 消息队列服务使用 Spring Boot+Netty 框架，使用 Reactor 模式进行开发

• MySQL 使用 Innodb 引擎

• 支持 Push 和 Pull 模式

• 主要面向 JAVA 服务端，因此使用 JMS 规范

• 服务间采用 JSON 格式作为数据传输

{

"queue":

"topic":

"jsonvalue":

}

5. 质量设计

1 消息队列管理后台，保证消息队列的可测试、可维护和可观察性

2 基于当前可投入的开发人员数目，采用多期开发来完成该系统

6. 演进规划

消息队列第一期 实现生产端、消费端的代码开发，打通生产到消费的逻辑，实现 push 消费模式，实现 mysql 数据库的 Sharded 分配扩展

消息队列第二期 实现 mysql 数据库的 Sharded 分片备份

消息队列第三期 实现短信通知、微信通知等运维级别的开发

消息队列第四期 支持 HTTP 协议的生产和消费，为后续不同应用和不同代码语言开发的服务做准备。实现 pull 模式满足不同需求的使用