前言

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

详细架构设计文档。自研的消息队列采用自研集群和 MySQL 存储。

词汇表

一、业务背景

业务发展很快，系统也越来越多，系统间协作的效率很低，业务上拆分的子系统越来越多，目前系统间的调用都是同步调用，由此带来几个明显的系统问题：

• 性能问题：各个子系统交互频繁，目前都是系统间通过接口调用的，性能极其低下。

• 耦合问题：当新增一个子系统时，例如如果要增加“广告子系统”，那么广告子系统需要开发新的接口给微博发布子系统调用。

• 效率问题：每个子系统提供的接口参数和实现都有一些细微的差别，导致每次都需要重新设计接口和联调接口，开发团队和测试团队花费了许多重复工作量。

基于以上背景，这些问题背后的根本原因在于架构上各业务子系统强耦合，我们需要引入消息队列进行系统解耦，将目前的同步调用改为异步通知。

二、约束和限制

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

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

三、总体架构

3.1 架构分析

3.1.1 高性能

系统一天内平均每秒写入消息数为 115 条，每秒读取的消息数是 1150 条，再考虑到系统的读写并不是完全平均的，设计的目标应该以峰值来计算。峰值一般取平均值的 3 倍，那么消息队列系统的 TPS 是 345，QPS 是 3450，这个量级的数据意味这并不 需要高性能。虽然根据当前业务规模计算的性能要求并不高，但业务会增长，因此系统设计需要考虑一定的性能余量。由于现在的基数较低，因此系统的设计目标按照峰值的 4 倍来计算，因此最终的性能要求是：TPS 为 1380，QPS 为 13800。TPS 为 1380 并不高，但是 QPS 为 13800 易筋经比较高了，因此高性能读取是复杂度之一，但这个高性能要求相比 Kafka 等系统来说也不是很高。

3.1.2 高可用

对于微博子系统来说，如果消息丢了，导致没有审核，然后触犯了国家法律法规，则是非常严重的事情；对于等级子系统来说，如果用户达到相应等级后，系统没有给他奖品和专属服务，则 VIP 用户会很不满意，导致用户流失从而损失收入，虽然也比较关键，但没有审核子系统丢消息那么严重。

综合来看，消息队列需要高可用性，包括消息写入、消息存储、消息读取都需要保证高可用性。

3.1.3 高可扩展性

消息队列的功能很明确，基本无需扩展，因此可扩展性不是这个消息队列的复杂度关键。

综合分析下来，消息队列的复杂性主要体现在几个方面：高性能消息读取、高可用消息 写入、高可用消息存储、高可用消息读取。

3.2 总体架构

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

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

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

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

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

四、详细设计

4.1 核心功能

• 消息发送流程

业务系统发布消息时，首先写入日志表，日志表写入成功就代表消息写入成功；后台线程再从日志表中读取消息写入记录，将消息内容写入消息表中。

• 消息消费流程

消息队列系统提供 SDK 供各业务系统调用，SDK 从配置中读取所有消息队列系统的服务器信息，轮流向所有服务器发起消息读取请求。

消息队列服务器需要记录每个消费者的消费状态，即当前消费者已经读取到了哪些消息，当收到消息读取请求时，返回下一条未被读取的消息给消费者。

4.2 关键设计

• 消息发送可靠性

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

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

• 消息存储可靠性

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

• 消息如何存储

每个消息队列对应一个 MySQL 表，消息队列名就是表名，包含的字段：消息 ID（递增生成）、消息内容、消息发布时间、消息发布者。日志表表名为 MQ_LOG ，包含的字段：日志 ID、发布者信息、发布时间、队列名称、消息内容。日志表需要及时清除已经写入消息表的日志数据，消息表最多保存 30 天的消息数据。

存储消息的整体流程：业务系统发布消息时，首先写入日志表，日志表写入成功就代表消息写入成功；后台线程再从日志表中读取消息写入记录，将消息内容写入消息表中。业务系统读取消息时，从消息表中读取。

4.3 设计规范

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

• MySQL 使用 Innodb 存储引擎

五、质量设计

5.1 安全设计

• 数据库连接字符串采用加密方式统一保存。

• 防止 SQL 注入（开发用代码实现，如参数化 sql 等技术）。

• 所有敏感业务操作均记录日志

5.2 可靠性设计

• 采用 Zookeeper 来做主备决测，主备服务器都连接到 zookeeper 建立自己的节点，主服务器的路径规则为“MQ/server/分区编号/master”，备机为“MQ/server/分区编号/slave”，节点类型为 EPHEMERAL。备机监听主机的节点 信息，当发现主服务器节点断连后，备服务器修改自己的状态，对外提供消息读取服务。

六、演进规划

消息队列一期基本功能快速上线，但要基本完善后才能正式推出给其他人用。