浅谈滚服游戏如果实现一键合服

pert · · 3161 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。
[原文链接](http://www.bugclosed.com/post/12) : http://www.bugclosed.com/post/12 ## 背景 近几年的游戏行业中,出现了各种各样的滚服游戏,包括页游,手游,H5游戏等等。滚服游戏和大服游戏的区别在于同时游戏人数,大服游戏是有很多用户在一起玩,甚至几十上百万玩家。而滚服游戏则一般会设计游戏在线上限,比如3000,达到上限则新开一组服务器,并引导用户进入新区。 滚服模式是游戏类型,技术架构和急功近利的坑钱策略等因素共同决定的,大服游戏包括绝大部分端游,以及类COC这样类型的游戏。另外,虽然像英雄联盟,王者荣耀这样的游戏也分服架构,但是这个并不是我理解中的“滚服游戏“,首先他们虽然分服,但是每个服的人数上限也是可以高达几十万,他们并不会发生频繁的合服情况。而滚服游戏更多是通过游戏策略设计,鼓励玩家花钱走捷径透支游戏生命周期,甚至几天即可独霸一个服务器。从而导致其他玩家望尘莫及,即使是花钱追也性价比极低,还不如进入一个新服重新开始。这就导致了新服一开,玩家即蜂拥而至,争先恐后练级升装备,以求最快速进入排行榜前列,如果努力一番发现落后了,可能就只能坐等下一个新服。这也导致了新服人数火爆,老服慢慢变成人烟凋零的村服,甚至没人的死服。 为了能够节约服务器带宽资源,同时让少数剩余的玩家能够玩得起来,就必须要要进行频繁的合服,把若干个互不相干的服务器玩家,合并到一个服里面;这样又开启一波玩家竞争和收割。 ##合服 前面提到滚服和大服两种模式,不管是哪种模式,合服的是时候,是需要将多个服的游戏数据合并在一起。不论数据库采用的是mysql,redis或者mongodb,数据库表的合并都是需要做到多服数据合并后的相容问题,不发生冲突或者遗漏。比如mysql,需要保证各个表合并时主键不冲突,如果业务有昵称不重复的设定,还需要保证昵称不重复。有时候合并还需要删除僵尸数据,此时需要注意删除的数据之间的逻辑关系是否一并清除,不能导致数据不一致,比如清除了一个半年不上线的玩家账号数据,但是在好友或者帮派中还残留关系。 ## 单服架构 业务模式在一定程度上会决定技术的选型,在滚服模式里面,游戏的在线人数要求都比较低,通常一个单进程架构就足以支持。所谓单服架构,并不一定整个后台只有一个服务器进程,可能会有其他辅助进程,但是主游戏逻辑只会有一个进程,同时架构也不支持游戏进程伸缩,达到该进程或者物理服务器上限,即从运营上重新开服,引导新的玩家进入新区,单服架构可以简单理解为如下架构模式: ![这里写图片描述](https://img-blog.csdn.net/20180513143736440?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RodW5kZXI1NDAwNw==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70) 从图中可见,每组服务器有自己独立的游戏进程和数据库,不同服务器之间的用户是物理隔离的。该架构的优势是简单易开发,服务器独立隔离,某组服务器需要停服调整或者宕机,不会影响其他服。缺点也来自单服独立部署,每次开新服都要重新部署数据库和游戏服务整套环境。合服的时候需要进行数据库的物理合并和迁移。 单服架构下的合服,需要进行物理数据库表的硬合并,需要注意主键字段是否冲突。可以通过两种方法防止主键冲突: + 合服的时候对所有主键进行修改,特别是uid,保证他们来自不同空间。 + 在设计之初即考虑合服的问题,从而数据在分配唯一uid的时候,即可为每个服进行分段处理,保证从一开始各个服的主键uid即不会冲突。 合服的步骤和操作一般都比较固定,成熟后可以针对自己特定的业务模式和表结构写脚本统一处理。 ## 大服架构 大服架构区别于单服架构是可以承载更多在线玩家,同时还有一定的伸缩性,一定程度上可以通过不断部署新服务器来扩充在线容量。在滚服模式的游戏中,也可以采用大服的设计思路和架构,从而在运维管理和合服方面得到极大便利,架构示意如下: ![这里写图片描述](https://img-blog.csdn.net/20180513144059171?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RodW5kZXI1NDAwNw==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70) 当然,该示意图和端游的分布式架构图有相似之处,但是也有所区别,因为此处的业务场景是用在滚服游戏中。该架构是一个原理说明示意,并非是线上运营架构,不同开发者会有不同的具体思路和设计偏好,比如还有类似好友,工会等并未列出,此处仅进行原理说明分析。 从图中可以看出,有多个不同的角色,说明如下: + 数据库,整个架构下只有唯一的DB,所有数据都集中保存; + DBServer,所有对数据库的操作都是通过DBServer进行,确保业务逻辑对数据库设计细节的分离; + Account/Name,对用户ID或者昵称的唯一性做保证,这个服务是全大区唯一; + GameServer,游戏逻辑服务,此处每个GameServer即是一个逻辑服,通过不断部署新的GameSever即实现了开服; + Login,登录逻辑和选路分配,此处是一键合服的关键所在,在合服策略配置里面保存了哪个服分配的哪个GameServer游戏进程地址,只需要通过调整这个策略配置即可控制用户进入的GameServer进程; 大服架构用户登录流程: 1. 用户在客户端能登陆界面选择3服的入口,并点击进入游戏。 2. Login模块收到用户进入s3的请求,从合服策略配置中查询到s3的GameServer入口地址,返回。 3. 客户端收到s3的GameServer地址,直接发起到s3的链接请求。 4. GameServer3 处理登录请求,并从DBServer获取用户信息返回给用户,没有信息则创建新角色。 5. 登录完成,进入了s3服。 #### 和单服架构的合服区别 单服架构的合服,之所以要进行数据处理和迁移,主要是2个原因: + 各个服数据库处于分离状态,需要物理合并到一起 + 主键唯一ID等信息有冲突,需要数据库修复处理 因为这2个原因,导致单服合服需要做大量的数据处理,导出,拷贝,迁移等,加大了合服操作的流程复杂度和出错的可能。从大服架构图可以发现,单服架构的2个合服难处已经自然消除了。Account分配唯一ID,在DB里面存储自然不会冲突;而且数据本来就放在一个库里面的,不存在需要迁移的问题。 #### 一键合服 通过以上分解可以发现,现在合服会极其方便;不用修改和迁移数据,甚至都不用停服,只需要通过一个工具在合服策略配置库里面对选路信息进行修改,修改用户的登录的游戏服务器。比如提供一个web修改页面,选择s1,s2,s3服合并,默认合并后由gameserver1提供服务,gameserver2和gameserver3即可停止下架,只需要一个http请求,将s2,s3的gameserver地址修改成gameserver1,即实现了合并。 合服后用户登录流程: 1. 用户还是选择3服的入口登录游戏。 2. Login模块得到用户要进入s3服,查询合服策略配置,得到s3服的服务地址,即gamesrver1,返回。 3. 用户得到gameserver1的地址,发起链接请求,进行登录。

有疑问加站长微信联系(非本文作者))

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:701969077

3161 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传