系统简介


我们在《江湖X:汉家江湖》系统中设计了一个每晚9点-10点的论剑系统,它的核心是一个带实时BAN/PICK的服务端自动计算的RANK框架。


如图:

 

《江湖X:汉家江湖》游戏论剑系统技术全解析_数据库

根据双方分数匹配上之后,双方轮流进行BAN人、选人。最后服务器计算自动战斗,并且下发录像,双方进行播放。


我们使用服务器组架构,当下的峰值数据大概是单服同时在线1万人,一个小时内触发的战斗量级可达数十万场。我们的战斗参数非常复杂,整场战斗在一台I7的PC机上计算约需要3-4秒,吃满一个core。所以这种量级的处理,放在单台服务器上是非常不科学的,估计同时一百人战斗就可以随便down掉这台服务器。


我们的设计目标是世界同服,所以需要一个架构来支撑理论上无限扩展的用户并发量级,所以在此设计一个分布式的处理架非常重要。


今天给大家分享一下,我们是如何设计和实现这套系统的。


汉家江湖的服务器组结构


先说一下设计前提:汉家江湖使用的是基于redis为核心的服务器组架构。一个逻辑服务器的实体下挂接了若干台ECS、DB、redis,以及一台双备的索引服务器。这样是为了提高同服在线玩家数和服务器稳定性,不了解的玩家可以看我们这篇文章:


两万人在线服务器架构和一些公有云使用心得( 


分布式的论剑计算系统


然而我们希望论剑系统是独立于服务器组之外的,也就是未来可以实现跨服务器组的论剑交互。所以我们给该玩法系统设定的是一个完全独立的玩法系统


1、系统架构

 

《江湖X:汉家江湖》游戏论剑系统技术全解析_消息总线_02

其中proxyServer可以认为是来自于不同服务器组的ECS实体,直接处理与客户端长连接的session。


其中各个名词解释如下:


1)Client 指unity游戏客户端;


2)RankProxy:Rank客户端在服务器上的代理,指当前的游戏服(SCUT SERVER),由于是世界服的,所以游戏服只充当代理角色;


3)RankDb 指RANK相关的数据库,同一个RANK群落(跨服战斗)指向同一个RANK数据库;


4)ComputeNode:RANK的计算节点,指一台服务器上部署的用于计算RANK战斗结果的程序;


5)RankComputeCluster:指ComputeNode的集合。


6)MatchServer配对服务器,一个Rank群落只有一个实例。


7)MessageBus:消息总线,提供订阅/发布接口,实现松耦合的分布式通信机制


2、功能要点:


· RankProxy


· 接受终端用户的所有行为(登录、登出、匹配、BAN/PICK、查询等)


· 与终端用户交互


· RankDb


· 一个RANK DB集中存储一个RANK群落的所有数据(从部署架构来说,我们可以实现同一区内的RANK战斗、甚至是跨大区的RANK战斗,区别只是在于RankDb)


· RANK DB自身高可用


· ComputeNode


· 集群计算(可以以集群的方式接受任务,任务可以分步到各个节点去分别计算)


· 幂等(任何一台实例计算结果一致,并且不会重复计算)


· MatchServer


· RANK匹配配对


· 主动清理过期RANK


· 为了防止单点故障,其自身应该是高可用的


· 各个服务器应该都是无状态的


· 原因是支持客户端断线重连,而客户端连接是根据网关路由分配RankProxy的,所以这里要求连到任何一个RankProxy都可以继续流程


· MessageBus、MQ


· 见消息总线说明


3、业务时序

 

《江湖X:汉家江湖》游戏论剑系统技术全解析_服务器_03

带颜色部分为使用消息总线通信


1)橙色部分使用MessageBus


2)绿色部分使用MQ


4、消息总线


我们使用互联网中间件来实现各个分布式模块的通信,以及分布式计算的集群消费模式。同时使用以下两种方案:


MessageBus


MessageBus使用redis的发布/订阅作为服务器间的实时通信信道,​​QQ号拍卖平台​​所有的通信均采用广播,根据业务属性,该广播信息为一次性的(可丢弃)。每个服务器根据自己的需要过滤消息。


MQ


战斗计算任务由于占用大量的CPU计算资源,我们需要搭建计算集群。使用阿里云MQ提供的集群消费模式,保证数据下发到一台计算节点。


成果


《江湖X:汉家江湖》上线近2个月以来,我们以弹性的云计算资源实现了峰值DAU10万用户规模的论剑,并发上千场战斗计算,一小时内十万级别的计算规模。在仅1个程序员维护服务器系统的情况下,保证系统稳定运行。


其中云服务器提供商(阿里云)出过几次MQ和Redis的BUG,导致我们的系统紊乱之外,没有任何运营事故。并且此框架未来足以支撑更大量级的用户,目前来看其理论瓶颈在于基于redis pub/sub的消息总线(MessageBus)的IOPS,未来需要的时候可以在这个点做基于业务逻辑的水平拆分。