《某公司FO产品总体技术方案.docx》由会员分享，可在线阅读，更多相关《某公司FO产品总体技术方案.docx（35页珍藏版）》请在三一办公上搜索。
1、腾讯科技（深圳）有限公司FO产品总体技术方案拟制：日期：审核：日期：版本号：XXX V1.0 腾讯科技（深圳）有限公司修订日期修订内容协议版本修订人目录目录31背景12概述12.1范围12.2引用标准12.3术语和定义12.4符号和缩略语13总体架构设计23.1设计原则23.1.1产品关联性原则23.1.2产品依赖原则23.2设计目标23.2.1路标规划23.3系统需求43.3.1系统软件需求43.3.2系统硬件需求43.3.3系统功能需求53.3.4系统性能需求53.4系统总体架构63.4.1系统物理架构63.4.2系统逻辑架构64关键技术分析84.1业务模型分析84.1.1目标用户84.1
2、.2用户入口84.1.3收费策略84.1.4产品依赖关系84.1.5典型业务过程94.2用户模型分析104.2.1用户基础信息104.2.2用户操作信息104.2.3用户流量信息124.3系统模型分析134.3.1Cluster Server134.3.2World Server144.3.3Zone server144.4性能容量分析154.4.1Cluster设备和流量需求154.4.2World设备和流量要求164.4.3Zone设备和流量需求174.4.4杂项设备和流量需求184.4.5总计224.5负载均衡分析224.5.1负载均衡策略224.5.2异地分布策略224.6容灾备份分析
3、225部署方案246风险分析及规避措施256.1硬件故障256.1.1机器、磁盘故障256.1.2IDC线路故障和黑客攻击256.2软件故障266.2.1Dir服务器266.2.2mysql266.2.3状态的转移和恢复276.2.4Zone服务器286.2.5Disp服务器286.2.6Log服务器287备选方案304版权所有 不得复制1 背景2 概述2.1 范围2.2 引用标准2.3 术语和定义名词解释2.4 符号和缩略语缩写英文描述中文描述3 总体架构设计3.1 设计原则3.1.1 产品关联性原则l 尽量保持产品的独立性l 在与其他产品进行交互时仅提供必须的接口，以减少复杂度和错误发生的
4、可能性。l 在与其他产品交互的时候都通过一个中间进程进行，以降低产品之间的耦合性l 与幻想关联的产品主要是：QQ和Q币支付系统。3.1.2 产品依赖原则l 尽可能重用公司内部已有的模块，以减少维护和开发的工作量。l 对于一些已有的产品，如果可以满足需求，直接整合到产品包中。l 由于幻想的特殊情况，目前幻想除了下载服务器以外，未重用任何模块或代码。3.2 设计目标3.2.1 路标规划阶段开始时间完成时间阶段目标和工作进度指标DEMO2003年10月272004年1月9DEMO的制作AHPLA12004年1月92004-3-12l 实现职业换装的人物头发换色l 完成以下界面: (1)开始选单 (2
5、)控制面板 (3)人物状态栏l 完成战斗攻击系统l 地图编辑器: (1)人物换色数据组织 (2)公用物件编辑 (3)图素拼接地表l 特效编辑器: 实现战斗被击特效编辑.AHPLA22004-3-122004-4-23l 增加道具系统l 构建游戏的第一个城镇AHPLA32004-4-232004-6-4l 组队系统l 基本技能系统l 职业换装系统l 称号系统l 放置野外宝箱AHPLA42004-6-42004-7-2l 功能性特性l 任务系统l 聊天系统l 怪物系统（怪物AI、怪物宝石）l 道具镶嵌和、改造、合成l 拜师系统l 好友系统(结合QQ)AHPLA52004-7-22004-7-30l
6、 建立跨组的游戏调试环境l 完成神明系统与异常状态的开发l 完成部分职业的技能 (考虑纸娃娃实现,延后进行)l 进行功能完善:AHPLA62004-7-302004-8-27l 完成界面的改进l 实现传送系统l Server后台功能实现l 加入修罗城,长乐村等地图AHPLA72004-8-27 2004-9-30l DIRSERVERl 邮件系统l 寄售系统l 完善神明及战斗异常状态的画面表现l 加入神武山迷宫地图l 加入2张野外地图AHPLA8 2004-9-302004-11-12l 开店系统l 职业技能AHPLA92004-11-122004-12-31游戏内容、数值调整Closed B
7、eta版本2004-12-312005-3-25测试、BUG修改、完善；Closed Beta22005年4月第一周2005年4月第四周l 商业技能（部分） l 怪物属性伤害（部分） l 道具镶嵌与合成（部分） l 任务（部分） Closed Beta3 2005年4月第一周2005年5月第四周l 卡片（部分）l 宠物系统（不含战斗） l 商业技能（全部） l 道具镶嵌和合成（全部） l 新地图黄金城和沙漠迷宫 l 语音聊天功能（可选） l 客户端支持平滑升级（可选） l 任务（部分） Open Beta 2005年4月第一周2005年6月第四周l 工会系统（基本功能） l 怪物属性伤害（全部
8、） l 支持代理服务器玩MMOG l 任务（部分） l 交通飞空艇 收费版2005年4月第一周2005年8月第二周l 宠物系统战斗（完成）l 半自由PK系统l 工会系统（工会战）l 任务（部分）l 新地图新大陆（可选）l 婚姻系统国庆版2005年4月第一周2005年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.16l Heatbeat 1.2.1l Libnet 1.1.2.13.3
9、.2 系统硬件需求DB服务器：l DL380G3l 标配：CPU P4 2.8G2l 内存：1G HPDDRRAM 2l 硬盘：36G 4 RAID5（100G）前端服务器：l PT2300GIIl 标配：CPU P4 2.4G2l 内存：1G DDRRAM 2l 硬盘：36G 1 NORAID日志服务器：l DL380G3l 标配：CPU P4 2.8G2l 内存：1G HPDDRRAM 2l 硬盘：146G 4 RAID5（400G）3.3.3 系统功能需求l 实时战斗模式，server用2D方式实现，client端可以为2D或者3D沙盘l 用QQ号码登录游戏，不需单独注册l 通过QQ s
10、erver验证，用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万注册用
11、户，1000-2000在线用户l 最大化容量：在同一个IDC大区下，支持50万在线用户，划分5-50个world，每个world支持 1 20万在线用户。以平均每台机器支撑600-1000用户计算，大概是一个500-800台机器的集群系统l 通过简单的配置，可以较方便地实现从最小化到最大化的伸缩l 考虑到实际情况，可能是在若干个大的地区，安装200台左右的机器，支持10万-20万在线用户。较小的地区采用更小的规模。l 响应速度要求：用户登陆时间5s，在一台1000-2000在线用户的机器上，用户操作延迟时间500ms3.4 系统总体架构3.4.1 系统物理架构FO采用两个Cluster，多个W
12、orld的方式。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的现有用户群
13、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堂等业务推出宣传性道具和地
14、图等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服
15、务器接收到帐号登录请求，记录相应的信息，并向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服务器将查询后的结果
16、返回给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 按每个
17、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访问Cl
18、uster 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
19、的移动请求，这样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的同步请求与用户移动的操作同时进行，故不再累
20、计。用户查询（网络游戏中角色查询货舱等操作）：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（包数）内网访问，3
21、5次/s数据库操作，其中25次/s的Update操作，10次/s的Select操作Zone：30K次/s（包数）外网请求4.2.3 用户流量信息用户登录请求流量（ClientDir）：200Bytes用户登录返回流量（DirClient）：1000Bytes用户登录请求流量（ClientZone）：100Bytes用户注销请求流量（ClientZone）：100Bytes用户登录返回流量（WorldZone）：5K（背包）+5K（任务）+3K（基本数据）+4K（大、小保管箱）+40*1K（邮件）62KBytes用户登录请求流量（WorldCluster）：100Bytes用户注销请求流量（Wo
22、rldCluster）：100Bytes用户更新流量（ZoneWorld）：5K（背包）+5K（任务）+3K（基本数据）+4K（大、小保管箱）=17Kbytes用户查询请求流量（ClientZone）：100Bytes用户查询返回流量（WorldZone）：7KBytes用户移动请求流量（ClientZone）：100Bytes用户攻击请求流量（ClientZone）：100Bytes聊天消息流量：140Bytes日志信息流量：140Bytes单位用户流量（平均用户每1秒攻击一次，每1秒移动一次，每一个用户平均被10个其他用户可见）：10200Bytes8Bit16Kps语音流量：15KpsZ
23、one切换流量：240Kps4.3 系统模型分析4.3.1 Cluster ServerCluster服务器包括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-2000在线用户的话，一个world可以同时在线10-20万人4.3.3 Zon
24、e serverZone服务器由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小时公式计算结果备注存储要求注册用户数单位用户信息10M100Byte1G其中100Byt
25、e是单位用户信息带宽要求（内网）在线人数（World与Cluster之间通信量）/在线时间8Bit500K*（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设备和流量要求
26、World：在线人数：4500注册人数：4500/5%90K平均在线时长：1小时公式计算结果备注存储要求注册用户数（角色数据保管箱数据邮件数据寄售物品数据）90K（75K12K120K0.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带宽要求（内网）在线人数（登录请求/在线时间
27、定时更新/更新频率查询请求/查询频率）8Bit4500*（16Bytes94Byte+12Byte）*8Bit=0.44Mbps登录请求5K（背包）+5K（任务）+3K（基本数据）+4K（大、小保管箱）+40*1K（邮件）/360016Bytes假定更新频率为3分钟，定时更新5K（背包）+5K（任务）+3K（基本数据）+4K（大、小保管箱）/18094Byte假定查询频率为10分钟，7K/600=12Byte带宽要求（外网）无机器要求2台G3双机热备，1台为主，另一台备份关键负荷分析35个/s的数据包，35次/s的数据库操作由于网络包数和数据库操作较少，所有没有瓶颈问题4.4.3 Zone设备
28、和流量需求假定一个Zone支持的最高人数为1500，平均人数为1000，每用户流量20Kbps，每用户平均游戏时间为1个小时。Zone：在线人数：1500单位用户流量：20Kbps平均在线时长：1小时公式计算结果备注存储要求无带宽要求（内网）在线人数（登录请求/在线时间定时更新/更新频率切换Zone/切换频率）8Bit1500*（15Bytes+94Bytes+167Bytes）*8Bit=3.3Mbps登录请求（5K（背包）+5K（任务）+3K（基本数据）+4K（大、小保管箱）+40*1K（邮件）/3600=15Byte假定更新频率为3分钟，定时更新（5K（背包）+5K（任务）+3K（基本数
29、据）+4K（大、小保管箱）/180=94Byte假定Zone切换频率为3分钟，切换Zone30K/180=167Byte带宽要求（外网）在线人数单位用户流量8Bit15002K8Bit24Mbps主要以用户最常使用的操作来进行评估，平均用户每1秒攻击一次，每1秒移动一次，每一个用户平均被10个其他用户可见。10200Bytes2K机器要求1台NRS关键负荷分析30K个/s的数据包30K个/s的数据包将成为数据访问的瓶颈，但由于估算是考虑的是每个人每秒移动并且攻击一次，而且每个人都将给其他10个看到，考虑到并不是所有人都在移动或攻击状态，所以按30统计，9K个/s的数据包也应该不会对系统造成访问
30、瓶颈4.4.4 杂项设备和流量需求1. 客户端版本检查服务器客户端版本大小：600M在线用户：500K平均在线时间：1小时更新版本用户：200K每天下载版本用户：20K公式计算结果备注存储要求客户端版本大小保存的版本数量600M21.2G带宽要求（内网）带宽要求（外网）（在线人数版本检测流量/在线时间更新用户数版本更新流量/更新时间下载人数下载流量）8Bit（500K0.28Byte200K291Bytes20K1K）8Bit0.67Gbps假设版本检测需要1K流量，版本检测1K/36000.28Byte假设每次更新大小为4M数据，每次更新时间为4小时，更新流量4M/3600/4291Byte
31、假设采用P2P技术可以节省80的带宽流量，600M/3600/24/4=1K机器要求3台NRS(千兆网卡)以每台可以支撑的有效负载流量250Mbps来计算关键负荷分析下载新版本流量为8Kbps考虑到公测的前一个月下载人数可能在100K左右，流量带宽将有0.8Gbps，所以在公测前期可能的带宽流量为1.3Gbps2. Web服务器公式计算结果备注存储要求带宽要求（内网）带宽要求（外网）150Mbps参考凯旋，凯旋的官网流量约为100MBps。机器要求2台NRS(千兆网卡)1台G3关键负荷分析3. 语音服务器在线人数：500K语音聊天人数：500K1050K单位语言流量（一路）：15Kbps公式计
32、算结果备注存储要求带宽要求（内网）带宽要求（外网）语音聊天人数语音流量50K15K725Mbps机器要求3台NRS(千兆网卡)以每台可以支撑的有效负载流量250Mbps来计算关键负荷分析4. Dir服务器在线人数：500K平均在线时长：1小时公式计算结果备注存储要求带宽要求（内网）带宽要求（外网）在线人数（Dir返回Client的游戏目录列表）8bit500K*（200+1000Byte）/3600*8Bit=1.33Mbps机器要求2台NRS双机热备，1台为主，另一台备份关键负荷分析5. 道具及支付服务器因为是相对比较独立的系统，FO 8月份开始收费，设备和带宽需求可以在Q3提。6. Con
33、fig和Monitor服务器提供配置和监控，没有外网流量。内网流量很少，可不予考虑。对于大的Cluster可以考虑使用2台，小的Cluster使用1台。a) 存储要求：无。b) 带宽要求：无。c) 机器要求：NRS，12台。7. Dispatch服务器Dispatch服务器用来转发消息和聊天信息。主要的流量在聊天消息和切换Zone消息。在线人数：4500聊天信息：0.5条/sZone切换次数：1次/3分钟公式计算结果备注存储要求带宽要求（内网）在线人数（聊天信息Zone切换信息）8bit4500*（140/230K/180）*8bit=8.52Mbps带宽要求（外网）机器要求1台NRS关键负荷
34、分析包数为2250个/s通信的包数也不是瓶颈8. Log服务器Log服务器主要用来记录玩家的操作，产生玩家的操作流水日志。每两秒产生一次记录。每天游戏时间以12小时计算。在线人数：4500平均在线时长：1小时日志信息：0.5条/s日志保存时间：30天公式计算结果备注存储要求在线人数日志信息每天日志条数日志保留时间4500*140*3600*12*30/2=408.2G带宽要求（内网）在线人数日志信息8bit4500140/28bit2.52Mbps带宽要求（外网）机器要求G3，4136GB硬盘，1台关键负荷分析包数为2250个/s流量带宽不是瓶颈，通信的包数也不是瓶颈4.4.5 总计一个Wor
35、ld的总计（按照一个World包含3个Zone计算）：带宽要求（内网）：0.44MBps（ZoneWorld的内网带宽）8.52Mbps（Dispatch内网带宽）2.52Mbps（日志内网带宽）11.48Mbps带宽要求（外网）：24Mbps(ClientZone的外网带宽)372Mbps设备要求：NRS：3台NRS（Zone）1台NRS（Dispatch）4（台）G3：2台G3（World）1台G3（Log）3（台）一个Cluster的总计：l 带宽要求（内网）为：0.22Mbps（WorldCluster）0.22Mbpsl 带宽要求（外网）为：1.33Mbps（ClientDir）0.
36、67Gbps（下载）150Mbps（Web）725Mbps（语音）1.56Gbpsl 设备需求：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的交互很少，因此对C
37、luster的影响较小。当随着World的增加导致Cluster的负载太大，单台服务器不能承受的时候，可以考虑对Cluster进行分布，每个Cluster仅为指定QQ号段服务，这样可以实现Cluster的负载均衡。4.5.2 异地分布策略FO的异地分布策略主要是如下两条：1 FO是否在某个城市进行分布和分布的数量，是根据该城市潜在的游戏用户数来确定，潜在用户数多，则分布的World多，否则分布的就少。2 覆盖度原则，每在一个城市进行分布，那么除了可以为该城市的游戏用户进行服务，也可以为相邻的一些城市提供服务。在进行分布的时候，遵循的原则是：使用尽可能少的分布点来达到尽可能大的覆盖度。4.6 容
38、灾备份分析对于游戏运营，最重要的就是用户数据，因此所有的手段都是围绕一个目的，即保证用户的数据不出现问题。为了保证极端情况下，尽可能的减少用户数据的损失，数据备份是一个很重要的手段。按照内测的数据，7MByte的存储，12320个角色，平均每个角色的存储为600Byte（压缩后）。按照每个角色基本数据的最大值来计算，每个角色的基本数据为30K：30K(单一角色存储)*90K（最高在线人数）*10(角色数与最高在线人数比)=27G（Byte）则保存30天的数据量为：27G*30=840G因为上述值是按照最保守的方式来计算的，实际的数据量应不超过上述计算值的一半，如果再加上压缩，那么实际的存储应不
39、超过200G。目前FO的备份方案是：分南北两个Cluster各自使用一个磁盘柜进行备份，备份的方式是采用全量备份，每天进行一次备份，备份时间为12个月（视具体情况而定）。如果有条件的话，还可以考虑使用磁带机进行备份，每周全量备份一次。5 部署方案目前FO的IDC分布规划如下图所示：分为南方和北方两个Cluster（分别针对不同的运营商：电信和网通）。每个大区下面根据需要有不同的World。每个world预计承载4500人，由三台服务器共同提供服务，单台服务器的负载在1500人左右。每个玩家的流量为15-20kbps。6 风险分析及规避措施总的来讲，FO运营的风险可以分成硬件故障和软件故障两大类
40、。硬件的故障包括机器的故障、磁盘故障、IDC线路故障，黑客攻击等。软件的故障包括数据库失效、程序失效等等。6.1 硬件故障针对不同的硬件故障，提供不同的应对策略。6.1.1 机器、磁盘故障对于机器或者磁盘故障的应对方式有两种：主动方式：对运行一些重要应用的机器提供HA方案，双机热备，当其中一台失效的时候，由另一台接管其工作。采用这种方式，可以把故障的处理时间降到10-20分钟。在另一台机器接管工作之后，再对故障机器进行检查，根据具体情况或更换、或修理。在失效机器恢复正常之后，失效机器以备机的身份重新开始服务。被动方式：对于运行不重要应用的机器提供快速更换服务。快速更换服务指的是机器上的应用和配
41、置都已准备好，当出现故障，需要更换其它机器时，只要对该服务器稍作修改就可以代替故障机器。FO采取的措施是两者皆用，一方面在每个IDC机房内准备一些备用机器，另一方面对关系到用户数据的机器提供HA方案。具体的方式是：每个IDC视支撑人数的大小，确定备用机器的数量和种类。对于小的IDC，保留2台备用机，1台为数据库备用机，1台为前端备用机。大的IDC，保留4台备用机，2台数据库，2台前端。对于Cluster（账号和计费）服务器和World（角色）服务器提供HA方案，保证用户的数据可以很快恢复访问。6.1.2 IDC线路故障和黑客攻击对于IDC线路故障和黑客攻击，这个没有方法完全避免问题，只能是尽量
42、减少损失。应对的措施主要是进行IDC分布，当一个IDC出现问题的时候，不会影响到另一个IDC的玩家。FO采用两个Cluster，多个World的方式。如果Cluster正常，只是World出现问题，那么受影响的只是出问题的World的玩家。如果Cluster出现问题，World正常，由于World和Cluster只在用户登入、登出和某些特殊的事件进行通信，那么已经登入的用户还是可以继续游戏，但是新用户将不能登陆。所有开放内网监听端口的应用程序都采用了限制IP的机制，报障了只有内部IP可以访问。所有开发外网监听端口的应用程序采用了超时限制和包大小限制来报障黑客的拒绝服务攻击，此外对于与外网的通信
43、协议采用了加密算法，防止黑客的探测攻击。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
