写点什么

第三次作业

用户头像
Geek_9cf7b5
关注
发布于: 2021 年 05 月 08 日

前言

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

词汇表

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 模式满足不同需求的使用

发布于: 2021 年 05 月 08 日阅读数: 50
用户头像

Geek_9cf7b5

关注

还未添加个人签名 2019.01.23 加入

还未添加个人简介

评论

发布
暂无评论
第三次作业