公司FO产品总体技术方案.doc

公司FO产品总体技术方案

34
2020年4月19日
文档仅供参考

FO产品总体技术方案

拟制:

日期:

审核:

日期:

版本号:XXX V1.0

腾讯科技(深圳)有限公司

修订日期
修订内容
协议版本
修订人

目录
目录 3
1 背景 1
2 概述 1
2.1 范围 1
2.2 引用标准 1
2.3 术语和定义 1
2.4 符号和缩略语 1
3 总体架构设计 2
3.1 设计原则 2
3.1.1 产品关联性原则 2
3.1.2 产品依赖原则 2
3.2 设计目标 2
3.2.1 路标规划 2
3.3 系统需求 4
3.3.1 系统软件需求 4
3.3.2 系统硬件需求 4
3.3.3 系统功能需求 5
3.3.4 系统性能需求 5
3.4 系统总体架构 6
3.4.1 系统物理架构 6
3.4.2 系统逻辑架构 6
4 关键技术分析 8
4.1 业务模型分析 8
4.1.1 目标用户 8
4.1.2 用户入口 8
4.1.3 收费策略 8
4.1.4 产品依赖关系 8
4.1.5 典型业务过程 9
4.2 用户模型分析 10
4.2.1 用户基础信息 10
4.2.2 用户操作信息 10
4.2.3 用户流量信息 12
4.3 系统模型分析 13
4.3.1 Cluster Server 13
4.3.2 World Server 14
4.3.3 Zone server 14
4.4 性能容量分析 15
4.4.1 Cluster设备和流量需求 15
4.4.2 World设备和流量要求 16
4.4.3 Zone设备和流量需求 17
4.4.4 杂项设备和流量需求 18
4.4.5 总计 22
4.5 负载均衡分析 22
4.5.1 负载均衡策略 22
4.5.2 异地分布策略 22
4.6 容灾备份分析 22
5 部署方案 24
6 风险分析及规避措施 25
6.1 硬件故障 25
6.1.1 机器、磁盘故障 25
6.1.2 IDC线路故障和黑客攻击 25
6.2 软件故障 26
6.2.1 Dir服务器 26
6.2.2 mysql 26
6.2.3 状态的转移和恢复 27
6.2.4 Zone服务器 28
6.2.5 Disp服务器 28
6.2.6 Log服务器 28
7 备选方案 30

1 背景
2 概述
2.1 范围
2.2 引用标准
2.3 术语和定义
名词
解释

2.4 符号和缩略语
缩写
英文描述
中文描述

3 总体架构设计
3.1 设计原则
3.1.1 产品关联性原则
l 尽量保持产品的独立性
l 在与其它产品进行交互时仅提供必须的接口,以减少复杂度和错误发生的可能性。
l 在与其它产品交互的时候都经过一个中间进程进行,以降低产品之间的耦合性
l 与幻想关联的产品主要是:QQ和Q币支付系统。
3.1.2 产品依赖原则
l 尽可能重用公司内部已有的模块,以减少维护和开发的工作量。
l 对于一些已有的产品,如果能够满足需求,直接整合到产品包中。
l 由于幻想的特殊情况,当前幻想除了下载服务器以外,未重用任何模块或代码。
3.2 设计目标
3.2.1 路标规划
阶段
开始时间
完成时间
阶段目标和工作进度指标
DEMO
10月27
1月9
DEMO的制作
AHPLA1
1月9
-3-12
l 实现职业换装的人物头发换色
l 完成以下界面: (1)开始选单 (2)控制面板 (3)人物状态栏
l 完成战斗攻击系统
l 地图编辑器: (1)人物换色数据组织 (2)公用物件编辑 (3)图素拼接地表
l 特效编辑器: 实现战斗被击特效编辑.
AHPLA2
-3-12
-4-23
l 增加道具系统
l 构建游戏的第一个城镇
AHPLA3
-4-23
-6-4
l 组队系统
l 基本技能系统
l 职业换装系统
l 称号系统
l 放置野外宝箱
AHPLA4
-6-4
-7-2
l 功能性特性
l 任务系统
l 聊天系统
l 怪物系统(怪物AI、怪物宝石)
l 道具镶嵌和、改造、合成
l 拜师系统
l 好友系统(结合QQ)
AHPLA5
-7-2
-7-30
l 建立跨组的游戏调试环境
l 完成神明系统与异常状态的开发
l 完成部分职业的技能 (考虑纸娃娃实现,延后进行)
l 进行功能完善:
AHPLA6
-7-30
-8-27
l 完成界面的改进
l 实现传送系统
l Server后台功能实现
l 加入修罗城,长乐村等地图
AHPLA7
-8-27
-9-30
l DIRSERVER
l 邮件系统
l 寄售系统
l 完善神明及战斗异常状态的画面表现
l 加入神武山迷宫地图
l 加入2张野外地图
AHPLA8
-9-30
-11-12
l 开店系统
l 职业技能
AHPLA9
-11-12
-12-31
游戏内容、数值调整
Closed Beta版本
-12-31
-3-25
测试、BUG修改、完善;
Closed Beta2
4月第一周
4月第四周
l 商业技能(部分)
l 怪物属性伤害(部分)
l 道具镶嵌与合成(部分)
l 任务(部分)
•Closed Beta3
4月第一周
5月第四周
l 卡片(部分)
l 宠物系统(不含战斗)
l 商业技能(全部)
l 道具镶嵌和合成(全部)
l 新地图黄金城和沙漠迷宫
l 语音聊天功能(可选)
l 客户端支持平滑升级(可选)
l 任务(部分)
•Open Beta
4月第一周
6月第四周
l 工会系统(基本功能)
l 怪物属性伤害(全部)
l 支持代理服务器玩MMOG
l 任务(部分)
l 交通飞空艇
收费版
4月第一周
8月第二周
l 宠物系统－战斗(完成)
l 半自由PK系统
l 工会系统(工会战)
l 任务(部分)
l 新地图－新大陆(可选)
l 婚姻系统
国庆版
4月第一周
9月第四周
l 全自由PK系统(预先完成)
l 攻城战
l 工会飞空艇

3.3 系统需求
3.3.1 系统软件需求
l Slackware Linux 10.1 Kernel 2.6.8.1(支持epoll、iptables)
l Cvs版本管理系统
l Mysql 4.0.16
l Heatbeat 1.2.1
l Libnet 1.1.2.1
3.3.2 系统硬件需求
DB服务器:
l DL380G3
l 标配:CPU P4 2.8G×2
l 内存:1G HPDDRRAM ×2
l 硬盘:36G ×4 RAID5(100G)
前端服务器:
l PT2300GII
l 标配:CPU P4 2.4G×2
l 内存:1G DDRRAM ×2
l 硬盘:36G ×1 NORAID
日志服务器:
l DL380G3
l 标配:CPU P4 2.8G×2
l 内存:1G HPDDRRAM ×2
l 硬盘:146G ×4 RAID5(400G)
3.3.3 系统功能需求
l 实时战斗模式,server用2D方式实现,client端能够为2D或者3D沙盘
l 用QQ号码登录游戏,不需单独注册
l 经过QQ server验证,用Kerberos方式实现C/S 128 bit 对称加密
l 用户登录后,能够在一个world的不同地图,不同server自由切换,不需重新连接
l 用户的前端连接和后台server处理逻辑分离,后台server的处理逻辑能够透明更新,不影响在线用户
l 支持后台自动更新。Client端需要更新版本时,用户能够一边玩一边后台更新。当登录用户已经下载好新版本超过一定比例时才要求强行更新(如大于80%)
l server尽可能支持不同版本的client登录。Client在升级失败时能够回退。
3.3.4 系统性能需求
l 最小化容量: 在一台机器上支持一个完整的world,约5-10万注册用户,1000- 在线用户
l 最大化容量:在同一个IDC大区下,支持50万在线用户,划分5-50个world,每个world支持 1 – 20万在线用户。以平均每台机器支撑600-1000用户计算,大概是一个500-800台机器的集群系统
l 经过简单的配置,能够较方便地实现从最小化到最大化的伸缩
l 考虑到实际情况,可能是在若干个大的地区,安装200台左右的机器,支持10万-20万在线用户。较小的地区采用更小的规模。
l 响应速度要求:用户登陆时间<5s,在一台1000- 在线用户的机器上,用户操作延迟时间<500ms
3.4 系统总体架构
3.4.1 系统物理架构
FO采用两个Cluster,多个World的方式。
FO的基本架构是由三层组成:
最上一层是Cluster,主要是管理帐号和计费,在一个Cluster中,一个帐号只能登录一次。
中间一层是World,主要是管理玩家角色数据,World之间的角色数据是互不相关的,同一个帐号能够在每个World中创立最多三个角色。
最下一层是Zone,负责游戏的逻辑,Zone服务器是用户直接相关的服务器,属于同一个World的Zone服务器之间共享角色数据。

3.4.2 系统逻辑架构
Cluster的逻辑架构图如下图所示:

World、Zone的逻辑架构图如下图所示:

4 关键技术分析
4.1 业务模型分析
4.1.1 目标用户
l 针对QQ,QQgame的现有用户群
l 18-25岁的年轻用户为主,学生族群为主
l 增加对女性玩家的吸引力,带动男性玩家
4.1.2 用户入口
l QQ幻想客户端桌面入口
l QQ客户端菜单入口
l QQgame游戏大厅入偶
l Game portal 网页入口
4.1.3 收费策略
l 会员制,包月用户收费,价格不高于40元人民币
l 会员制,包周用户收费,价格不高于15元人民币
l 虚拟物品贩卖收费,单价0.1Q币~10Q币不等
4.1.4 产品依赖关系
l QQ客户端上的入口及会员标志等多种表现形式
l QQgame 游戏大厅入口,游戏内可进行QQgame的小游戏等
l 与短信、QQ音乐等增殖业务结合增加收入
l QQ秀,QQ堂等业务推出宣传性道具和地图等
l 内嵌QQ和QQmail发送功能
l 宠物设计与QQ宠物结合一致
4.1.5 典型业务过程
一个完整的用户登录过程如下图所示:
l 用户输入帐号和密码,客户端开始连接QQ签名服务器。
l QQ签名服务器根据用户输入的帐号和密码,进行鉴权,并返回签名。
l 客户端连接Dir服务器,试图获得Zone服务器的目录列表。
l Dir服务器返回当前可用的Zone服务器列表以及负载信息。
l 用户选择要连接的Zone服务器,发送连接请求和签名信息。
l Zone接到请求后,验证该签名,并向World服务器发送帐号登录请求。
l World服务器接收到帐号登录请求后,向Cluster服务器转发该请求。
l Cluster服务器接收到帐号登录请求,记录相应的信息,并向World服务器返回应答。
l World服务器转发该应答到对应的Zone服务器。
l Zone服务器得到应答,进行有关的帐号登录处理,并通知客户端。

一个典型的用户操作过程:
l Client向Zone服务器发送移动或打斗的操作。
l Zone服务器计算出Client移动的新位置或打斗的动作,将它反射给其它Client,使得其它用户可见。
l Zone服务器定时将Client操作后的数据同步给World服务器
一个典型的用户查询过程:
l Client向Zone服务器发送查询请求。
l Zone服务器将此请求发送给World服务器。
l World服务器将查询后的结果返回给Zone服务器。
l Zone服务器将查询结果返回给Client。
4.2 用户模型分析
4.2.1 用户基础信息
一个Cluster支持的在线用户为500K
一个World支持的在线用户为5000
一个Zone支持的在线用户为1500
单个用户平均在线时间:1小时/每天
在线与注册用户比例:5%
活跃与注册用户比例:20%
4.2.2 用户操作信息
用户登录:
l 按每个Cluster有500K同时在线人数,平均每人每天1小时的在线时长,则将造成约140次/s登录请求,这样World将有140次/s访问Cluster(内网访问),Cluster将有140次/s访问Cluster DB(数据库操作)。
l 按每个World有5000人同时在线人数,平均每人每天1小时的在线时长,则将造成约1.4次/s登录请求,这样Zone将有1.4次/s访问World(内网访问),World将有1.4/s访问World DB(数据库操作)。
l 按每个Zone有1500人同时在线人数,平均每人每天1小时的在线时长,则将造成0.42次/s登录请求,这样Client将有0.42次/s访问Zone(外网访问)。
用户注销:
l 按每个Cluster有500K同时在线人数,平均每人每天1小时的在线时长,则将造成约140次/s注销请求,这样World将有140次/s访问Cluster(外网访问),Cluster将有140次/s访问Cluster DB(数据库操作)。
l 按每个World有5000人同时在线人数,平均每人每天1小时的在线时长,则将造成约1.25次/s注销请求,这样Zone将有1.4次/s访问World(内网访问),World将有1.4/s访问World DB(数据库操作)。
l 按每个Zone有1500人同时在线人数,平均每人每天1小时的在线时长,则将造成0.42次/s注销请求,这样Client将有0.42次/s访问Zone(外网访问)。
用户移动(网络游戏中的角色行走):
l 按每个Zone有1500人同时在线人数,平均每人每天1小时在线时长,每人每秒移动1次,每个用户平均被10个其它用户可见,则造成15K次/s的移动请求,这样Client将有15K次/s访问Zone(外网访问)。
l 按每个World有5000人同时在线人数,每3分钟同步一次Zone的数据,则将造成27次/s同步请求,这样Zone将有27/s访问World(内网访问),World将有25/s访问World DB(数据库操作)。
用户攻击(网络游戏中的角色打斗):
l 按每个Zone有1500人同时在线人数,平均每人每天1小时在线时长,每人每秒攻击1次,每个用户平均被10个其它用户可见,则造成15K次/s的攻击请求,这样Client将有15K次/s访问Zone(外网访问)。
l Zone与World的同步请求与用户移动的操作同时进行,故不再累计。
用户查询(网络游戏中角色查询货舱等操作):
l 按每个Zone有1500人同时在线人数,每10分钟查询一次数据,则造成2.5次/s查询请求,这样Client将有2.5次/s访问Zone(外网访问)。
l 按每个World有5000人同时在线人数,每10分钟查询一次数据,则造成8.3次/s查询请求,这样Zone将有7.5次/s访问World(内网访问),World将有8.3次/s访问World DB(数据库操作)。
总计:
Cluster:280次/s(包数)内网访问,280次/s数据库操作,其中140次/s的Select操作,140次/s的Update操作
World:35次/s(包数)内网访问,35次/s数据库操作,其中25次/s的Update操作,10次/s的Select操作
Zone:30K次/s(包数)外网请求
4.2.3 用户流量信息
用户登录请求流量(Client－Dir):200Bytes
用户登录返回流量(Dir－Client):1000Bytes
用户登录请求流量(Client－Zone):100Bytes
用户注销请求流量(Client－Zone):100Bytes
用户登录返回流量(World－Zone):5K(背包)+5K(任务)+3K(基本数据)+4K(大、小保管箱)+40*1K(邮件)＝62KBytes
用户登录请求流量(World－Cluster):100Bytes
用户注销请求流量(World－Cluster):100Bytes
用户更新流量(Zone－World):5K(背包)+5K(任务)+3K(基本数据)+4K(大、小保管箱)=17Kbytes
用户查询请求流量(Client－Zone):100Bytes
用户查询返回流量(World－Zone):7KBytes
用户移动请求流量(Client－Zone):100Bytes
用户攻击请求流量(Client－Zone):100Bytes
聊天消息流量:140Bytes
日志信息流量:140Bytes
单位用户流量(平均用户每1秒攻击一次,每1秒移动一次,每一个用户平均被10个其它用户可见):10×200Bytes×8Bit＝16Kps
语音流量:15Kps
Zone切换流量:240Kps
4.3 系统模型分析
4.3.1 Cluster Server
Cluster服务器包括cluster_login和db_process,cluster_login负责与World Server交互,并维护Online Account Table,对数据库的访问由db_process负责。
4.3.2 World Server
一个world能够包含多个zone server,每个zone server管理一块或者多块地图。一个world最多包括100个zone server,每个处理1000- 在线用户的话,一个world能够同时在线10-20万人
4.3.3 Zone server

Zone服务器由zone_connect、zone_disp和zone_server构成。
zone_connect负责接收来自客户端的连接,并进行解密,并把消息传递给zone_server进行处理。
zone_server负责进行逻辑处理,并根据处理结果或者转给zone_disp并交由其它zone_server进行处理,或者交由World服务器进行处理。
4.4 性能容量分析
4.4.1 Cluster设备和流量需求
Cluster:
在线人数:500K
注册人数:500K/5%＝10M
平均在线时长:1小时

公式
计算结果
备注
存储要求
注册用户数×单位用户信息
10M×100Byte＝1G
其中100Byte是单位用户信息
带宽要求(内网)
在线人数×(World与Cluster之间通信量)/在线时间×8Bit
500K*(100Byte+100Byte)/3600*8Bit=0.22Mbps
其中第一个100Byte是Login的开销,后100Byte是Logout的开销
带宽要求(外网)

无

机器要求

2台G3
双机热备,1台为主,另一台备份
关键负荷分析

280个/s的数据包
280次/s的数据库操作
数据包数不是瓶颈,
其中140次/s的Select操作(Login),140次/s的Update操作(Logout),由于Select和Update的数据量较小,不会造成数据库的访问瓶颈

4.4.2 World设备和流量要求
World:
在线人数:4500
注册人数:4500/5%＝90K
平均在线时长:1小时

公式
计算结果
备注
存储要求
注册用户数×(角色数据＋保管箱数据＋邮件数据＋寄售物品数据)
90K×(75K＋12K＋120K＋0.6K)=18.68G
角色数据＝(5K(背包)+5K(任务)+12K(赠送记录)+3K(基本数据))*3(每个帐号能够创立3个角色)＝75K
保管箱数据＝4K(大、小保管箱) *3(每个帐号能够创立3个角色)＝12K
邮件数据＝1K(每封)*40(每个角色)*3(每个帐号能够创立3个角色)＝120K
寄售物品数据＝(5(byte)*40)(寄售物品)*3(每个帐号能够创立3个角色)＝0.6K
带宽要求(内网)
在线人数×(登录请求/在线时间＋定时更新/更新频率＋查询请求/查询频率)×8Bit
4500*(16Bytes＋94Byte+12Byte)*8Bit=0.44Mbps
登录请求＝5K(背包)+5K(任务)+3K(基本数据)+4K(大、小保管箱)+40*1K(邮件)/3600＝16Bytes
假定更新频率为3分钟,
定时更新＝5K(背包)+5K(任务)+3K(基本数据)+4K(大、小保管箱)/180＝94Byte
假定查询频率为10分钟,
7K/600=12Byte
带宽要求(外网)

无

机器要求

2台G3
双机热备,1台为主,另一台备份
关键负荷分析

35个/s的数据包,
35次/s的数据库操作
由于网络包数和数据库操作较少,所有没有瓶颈问题
4.4.3 Zone设备和流量需求
假定一个Zone支持的最高人数为1500,平均人数为1000,每用户流量20Kbps,每用户平均游戏时间为1个小时。
Zone:
在线人数:1500
单位用户流量:20Kbps
平均在线时长:1小时

公式
计算结果
备注
存储要求

无

带宽要求(内网)
在线人数×(登录请求/在线时间＋定时更新/更新频率＋切换Zone/切换频率)×8Bit
1500*(15Bytes+94Bytes+167Bytes)*8Bit=3.3Mbps
登录请求＝(5K(背包)+5K(任务)+3K(基本数据)+4K(大、小保管箱)+40*1K(邮件))/3600=15Byte
假定更新频率为3分钟,
定时更新＝(5K(背包)+5K(任务)+3K(基本数据)+4K(大、小保管箱))/180=94Byte
假定Zone切换频率为3分钟,
切换Zone＝30K/180=167Byte
带宽要求(外网)
在线人数×单位用户流量×8Bit
1500×2K×8Bit＝24Mbps
主要以用户最常使用的操作来进行评估,平均用户每1秒攻击一次,每1秒移动一次,每一个用户平均被10个其它用户可见。
10×200Bytes＝2K
机器要求

1台NRS

关键负荷分析

30K个/s的数据包
30K个/s的数据包将成为数据访问的瓶颈,但由于估算是考虑的是每个人每秒移动而且攻击一次,而且每个人都将给其它10个看到,考虑到并不是所有人都在移动或攻击状态,因此按30％统计,9K个/s的数据包也应该不会对系统造成访问瓶颈

4.4.4 杂项设备和流量需求
1. 客户端版本检查服务器
客户端版本大小:600M
在线用户:500K
平均在线时间:1小时
更新版本用户:200K
每天下载版本用户:20K

公式
计算结果
备注
存储要求
客户端版本大小×保存的版本数量
600M×2＝1.2G

带宽要求(内网)

带宽要求(外网)
(在线人数×版本检测流量/在线时间＋更新用户数×版本更新流量/更新时间＋下载人数×下载流量)×8Bit
(500K×0.28Byte＋200K×291Bytes＋20K×1K)×8Bit＝0.67Gbps
假设版本检测需要1K流量,版本检测＝1K/3600＝0.28Byte
假设每次更新大小为4M数据,每次更新时间为4小时,更新流量＝4M/3600/4＝291Byte
假设采用P2P技术能够节省80％的带宽流量,600M/3600/24/4=1K
机器要求

3台NRS(千兆网卡)
以每台能够支撑的有效负载流量250Mbps来计算
关键负荷分析

下载新版本流量为8Kbps
考虑到公测的前一个月下载人数可能在100K左右,流量带宽将有0.8Gbps,因此在公测前期可能的带宽流量为1.3Gbps
2. Web服务器

公式
计算结果
备注
存储要求

带宽要求(内网)

带宽要求(外网)

150Mbps
参考<凯旋>,<凯旋>的官网流量约为100MBps。
机器要求

2台NRS(千兆网卡)＋1台G3

关键负荷分析

3. 语音服务器
在线人数:500K
语音聊天人数:500K×10％＝50K
单位语言流量(一路):15Kbps

公式
计算结果
备注
存储要求

带宽要求(内网)

带宽要求(外网)
语音聊天人数×语音流量
50K×15K＝725Mbps

机器要求

3台NRS(千兆网卡)
以每台能够支撑的有效负载流量250Mbps来计算
关键负荷分析

4. Dir服务器
在线人数:500K
平均在线时长:1小时

公式
计算结果
备注
存储要求

带宽要求(内网)

带宽要求(外网)
在线人数×(Dir返回Client的游戏目录列表)×8bit
500K*(200+1000Byte)/3600*8Bit=1.33Mbps

机器要求

2台NRS
双机热备,1台为主,另一台备份
关键负荷分析

5. 道具及支付服务器
因为是相对比较独立的系统,FO 8月份开始收费,设备和带宽需求能够在Q3提。
6. Config和Monitor服务器
提供配置和监控,没有外网流量。内网流量很少,可不予考虑。
对于大的Cluster能够考虑使用2台,小的Cluster使用1台。
a) 存储要求:无。
b) 带宽要求:无。
c) 机器要求:NRS,1—2台。
7. Dispatch服务器
Dispatch服务器用来转发消息和聊天信息。主要的流量在聊天消息和切换Zone消息。
在线人数:4500
聊天信息:0.5条/s
Zone切换次数:1次/3分钟

公式
计算结果
备注
存储要求

带宽要求(内网)
在线人数×(聊天信息＋Zone切换信息)×8bit
4500*(140/2＋30K/180)*8bit=8.52Mbps

带宽要求(外网)

机器要求

1台NRS

关键负荷分析

包数为2250个/s
通信的包数也不是瓶颈
8. Log服务器
Log服务器主要用来记录玩家的操作,产生玩家的操作流水日志。每两秒产生一次记录。每天游戏时间以12小时计算。
在线人数:4500
平均在线时长:1小时
日志信息:0.5条/s
日志保存时间:30天

公式
计算结果
备注
存储要求
在线人数×日志信息×每天日志条数×日志保留时间
4500*140*3600*12*30/2=408.2G

带宽要求(内网)
在线人数×日志信息×8bit
4500×140/2×8bit＝2.52Mbps

带宽要求(外网)

机器要求

G3,4×136GB硬盘,1台

关键负荷分析

包数为2250个/s
流量带宽不是瓶颈,通信的包数也不是瓶颈
4.4.5 总计
一个World的总计(按照一个World包含3个Zone计算):
带宽要求(内网):0.44MBps(Zone－World的内网带宽)＋8.52Mbps(Dispatch内网带宽)＋2.52Mbps(日志内网带宽)＝11.48Mbps
带宽要求(外网):24Mbps(Client－Zone的外网带宽)×3＝72Mbps
设备要求:
NRS:3台NRS(Zone)＋1台NRS(Dispatch)＝4(台)
G3:2台G3(World)＋1台G3(Log)＝3(台)

一个Cluster的总计:
l 带宽要求(内网)为:0.22Mbps(World－Cluster)＝0.22Mbps
l 带宽要求(外网)为:1.33Mbps(Client－Dir)＋0.67Gbps(下载)＋150Mbps(Web)＋725Mbps(语音)＝1.56Gbps
l 设备需求:
NRS:2(Dir)+1(Config)+1(Web)+2(Voice)+1(Moniter)+2(版本检查)+3(千兆下载,或者12台百兆下载)+1(QQ验证)=13(台)
G3:1(Cluster)*2 +1(Web DB)= 3(台)
4.5 负载均衡分析
4.5.1 负载均衡策略
FO的负载均衡以增加新的World作为负载均衡的主要手段。每一个World是一个相对独立的部分,能够支撑玩家在其中进行游戏。
World的增加,会导致Cluster的负载增加,由于Cluster与World的交互很少,因此对Cluster的影响较小。
当随着World的增加导致Cluster的负载太大,单台服务器不能承受的时候,能够考虑对Cluster进行分布,每个Cluster仅为指定QQ号段服务,这样能够实现Cluster的负载均衡。
4.5.2 异地分布策略
FO的异地分布策略主要是如下两条:
1． FO是否在某个城市进行分布和分布的数量,是根据该城市潜在的游戏用户数来确定,潜在用户数多,则分布的World多,否则分布的就少。
2． 覆盖度原则,每在一个城市进行分布,那么除了能够为该城市的游戏用户进行服务,也能够为相邻的一些城市提供服务。在进行分布的时候,遵循的原则是:使用尽可能少的分布点来达到尽可能大的覆盖度。
4.6 容灾备份分析
对于游戏运营,最重要的就是用户数据,因此所有的手段都是围绕一个目的,即保证用户的数据不出现问题。为了保证极端情况下,尽可能的减少用户数据的损失,数据备份是一个很重要的手段。
按照内测的数据,7MByte的存储,12320个角色,平均每个角色的存储为600Byte(压缩后)。
按照每个角色基本数据的最大值来计算,每个角色的基本数据为30K:
30K(单一角色存储)*90K(最高在线人数)*10(角色数与最高在线人数比) = 27G(Byte)
则保存30天的数据量为:
27G*30 = 840G
因为上述值是按照最保守的方式来计算的,实际的数据量应不超过上述计算值的一半,如果再加上压缩,那么实际的存储应不超过200G。
当前FO的备份方案是:
分南北两个Cluster各自使用一个磁盘柜进行备份,备份的方式是采用全量备份,每天进行一次备份,备份时间为1~2个月(视具体情况而定)。
如果有条件的话,还能够考虑使用磁带机进行备份,每周全量备份一次。
5 部署方案
当前FO的IDC分布规划如下图所示:

分为南方和北方两个Cluster(分别针对不同的运营商:电信和网通)。
每个大区下面根据需要有不同的World。
每个world预计承载4500人,由三台服务器共同提供服务,单台服务器的负载在1500人左右。
每个玩家的流量为15-20kbps。
6 风险分析及规避措施
总的来讲,FO运营的风险能够分成硬件故障和软件故障两大类。硬件的故障包括机器的故障、磁盘故障、IDC线路故障,黑客攻击等。
软件的故障包括数据库失效、程序失效等等。
6.1 硬件故障
针对不同的硬件故障,提供不同的应对策略。
6.1.1 机器、磁盘故障
对于机器或者磁盘故障的应对方式有两种:
主动方式:
对运行一些重要应用的机器提供HA方案,双机热备,当其中一台失效的时候,由另一台接管其工作。采用这种方式,能够把故障的处理时间降到10-20分钟。在另一台机器接管工作之后,再对故障机器进行检查,根据具体情况或更换、或修理。在失效机器恢复正常之后,失效机器以备机的身份重新开始服务。
被动方式:
对于运行不重要应用的机器提供快速更换服务。快速更换服务指的是机器上的应用和配置都已准备好,当出现故障,需要更换其它机器时,只要对该服务器稍作修改就能够代替故障机器。
FO采取的措施是两者皆用,一方面在每个IDC机房内准备一些备用机器,另一方面对关系到用户数据的机器提供HA方案。
具体的方式是:
每个IDC视支撑人数的大小,确定备用机器的数量和种类。对于小的IDC,保留2台备用机,1台为数据库备用机,1台为前端备用机。大的IDC,保留4台备用机,2台数据库,2台前端。
对于Cluster(账号和计费)服务器和World(角色)服务器提供HA方案,保证用户的数据能够很快恢复访问。
6.1.2 IDC线路故障和黑客攻击
对于IDC线路故障和黑客攻击,这个没有方法完全避免问题,只能是尽量减少损失。
应正确措施主要是进行IDC分布,当一个IDC出现问题的时候,不会影响到另一个IDC的玩家。
FO采用两个Cluster,多个World的方式。
如果Cluster正常,只是World出现问题,那么受影响的只是出问题的World的玩家。
如果Cluster出现问题,World正常,由于World和Cluster只在用户登入、登出和某些特殊的事件进行通信,那么已经登入的用户还是能够继续游戏,可是新用户将不能登陆。
所有开放内网监听端口的应用程序都采用了限制IP的机制,报障了只有内部IP能够访问。
所有开发外网监听端口的应用程序采用了超时限制和包大小限制来报障黑客的拒绝服务攻击,另外对于与外网的通信协议采用了加密算法,防止黑客的探测攻击。
6.2 软件故障
6.2.1 Dir服务器
Dir服务器是客户端拉取游戏分区信息的服务器,是用户进行游戏的第一个入口。一个Dir服务器为一个cluster服务,如果Dir服务器出现故障,会对用户的登陆产生严重的影响。由于Dir服务器不保存任何数据,能够说是没有状态的。因此Dir服务器能够采用对称多处理的方式。Dir服务器的信息来源是Zone服务器上报的信息,为了提供容错,Zone服务器将向两个Dir服务器同时上报同样的信息,这样在两个Dir服务器中产生完全相同的两份数据,当其中一台Dir服务器失效的时候,另一台能够继续提供服务。在客户端能够提供一个访问策略,先随即选择一台Dir服务器,如果该服务器不能提供服务,再选择另一台Dir服务器。
对于可伸缩性的考虑。由于Dir服务器是为Cluster服务的,因此,Dir服务器的负载变动的范围可能会比较大。采用两个Dir服务器对称处理的方式提供了高可用性,也提高了一倍的负载能力,可是还是可能会出现负载过大的情况。如果两台Dir服务器不能满足服务器的需要,那么能够考虑复制的方式,以这两台服务器作为主服务器,把自己的信息push到其它的从服务器上,这样就能够实现任意的负载平衡。
6.2.2 mysql
FO的数据服务器使用mysql,所有有关的游戏数据都经过mysql来进行存取。对于游戏而言,数据的安全性是第一位的。在FO中,涉及到数据的主要是两类服务器,Clu