前言

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

词汇表

Reactor: 网络编程模式

Netty: 开源的网络编程框架

MySQL：关系型数据库

1.业务背景

随着游戏业务的不断发展，不同级别的子系统越来越多，系统之间协作效率越来越低。

比如玩家充值之后，充值完成之后，需要通知 VIP 系统，VIP 系统需要判断玩家等级，不同等级通知不同礼品发放，通知各种子系统.....带来了以下问题：

1. 不同子系统的接口各有不同；

2. 一个子系统调用失败，需要各种幂等重试；

3. 子系统之间的耦合性高；

4. 当新增一个子系统，需要新开接口来调用；

5. 测试和维护的效率低下，增加工作量；

基于以上背景。将同步调用改为异步调用，引入消息队列进行系统解耦

2.约束和限制

1. 中间件团队规模不大，大约 6 人左右。

2. 目前整个业务系统是单机房部署，没有双机房。

3. 系统的需要嵌入到已有运维体系，且维护成本不能太高

4. 需要保证可用性，丢消息对业务影响严重

3.总体架构

3.1 架构分析

3.1.1 高可用

需要，保证各种消息不丢失；在主服务器宕机时，及时将备机提升为主机，同时保证消息的备份；

3.1.2 高性能

在不增加系统的复杂度的情况下，尽量保证高性能；

3.1.3 可扩展

不需要，消息队列的功能相对简单；

3.1.4 可维护

各种维护操作要方便，例如收发消息情况、权限控制、上下线等；

3.1.5 低成本

保证功能的前提下，尽量保证低成本；

3.2 总体架构

1. Java 语言编写消息队列服务器；

2. 消息存储采用 MySQL；

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

4. SDK 轮询服务器进行消息写入；

5. SDK 轮询服务器进行消息读取；

6. MySQL 双机保证消息尽量不丢；

7. 使用 Netty 自定义消息格式，并且支持 HTTP 接口；

4.详细设计

4.1 核心功能

4.1.1 消息发送流程

1. 生产者产生消息（保证每个消息 ID 唯一），根据接口发送给服务器；

2. 算法考虑：轮询、随机、哈希三种算法

3. 幂等重试：当发送消息之后，服务器未回复 ACK 时，生产者在超时后，幂等重新发送消息；

4. 设置生产者生产的消息是否立即发送还是累计多少条消息再发送；

5. 消息数据是否可压缩；

4.1.2 消息消费过程

1. 服务器提供相应的接口，供消费者来消费；

2. 服务器记录当前消息的消费索引，在消费者确定消息已消费时，更新相应的消息索引；

4.1.3 主备架构

1. 备服务器不对外提供服务；

2. 备服务器只负责从主服务器拉取消息，来保证数据的高可用；

3. 在主服务器宕机时，根据 zookeeper 将备服务器提升为主服务器；

4.2 关键设计

4.2.1 消息发送高可靠

1. 生产者未收到服务器 ACK 回复时，超时幂等重试；

4.2.2 消息存储高可靠

1. 利用 MySQL InnoDB 存储引擎来存储消息；

2. MySQL 提供主备架构，保证消息的高可用；

4.3 设计规范

5.质量设计

6.演进规范

1. 一期：完成消息发送流程、消息存储以及消息消费功能；

2. 二期：完成主备切换流程、消息发送高可用、消息存储高可用可靠性；

3. 三期：完成消息队列管理后台，保证系统的可测试性、可维护性、可观测性，提供给所有需要消息队列系统的子系统线上正式使用。