某公司FO产品总体技术方案

腾讯科技〔深圳〕有限公司PAGEPAGE4版权所有不得复制FOFO产品总体技术方案拟制：日期：审核：日期：版本号：版本号：XXXV1.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 用户入口 84.1.3 收费策略 84.1.4 产品依赖关系 84.1.5 典型业务过程 94.2 用户模型分析 104.2.1 用户根底信息 104.2.2 用户操作信息 104.2.3 用户流量信息 124.3 系统模型分析 134.3.1 ClusterServer 134.3.2 WorldServer 144.3.3 Zoneserver 144.4 性能容量分析 154.4.1 Cluster设备和流量需求 154.4.2 World设备和流量要求 164.4.3 Zone设备和流量需求 174.4.4 杂项设备和流量需求 184.4.5 总计 224.5 负载均衡分析 224.5.1 负载均衡策略 224.5.2 异地分布策略 224.6 容灾备份分析 225 部署方案 246 风险分析及躲避措施 256.1 硬件故障 256.1.1 机器、磁盘故障 256.1.2 IDC线路故障和黑客攻击 256.2 软件故障 266.2.1 Dir效劳器 266.2.2 mysql 266.2.3 状态的转移和恢复 276.2.4 Zone效劳器 286.2.5 Disp效劳器 286.2.6 Log效劳器 287 备选方案 30PAGE14版权所有不得复制背景概述范围引用标准术语和定义名词解释符号和缩略语缩写英文描述中文描述总体架构设计设计原那么产品关联性原那么尽量保持产品的独立性在与其他产品进行交互时仅提供必须的接口，以减少复杂度和错误发生的可能性。在与其他产品交互的时候都通过一个中间进程进行，以降低产品之间的耦合性与梦想关联的产品主要是：QQ和Q币支付系统。产品依赖原那么尽可能重用公司内部已有的模块，以减少维护和开发的工作量。对于一些已有的产品，如果可以满足需求，直接整合到产品包中。由于梦想的特殊情况，目前梦想除了下载效劳器以外，未重用任何模块或代码。设计目标路标规划阶段开始时间完成时间阶段目标和工作进度指标DEMO2003年10月272004年1月9DEMO的制作AHPLA12004年1月92实现职业换装的人物头发换色完成以下界面:(1)开始选单(2)控制面板(3)人物状态栏完成战斗攻击系统地图编辑器:(1)人物换色数据组织(2)公用物件编辑(3)图素拼接地表特效编辑器:实现战斗被击特效编辑.AHPLA222增加道具系统构建游戏的第一个城镇AHPLA322组队系统根本技能系统职业换装系统称号系统放置野外宝箱AHPLA422功能性特性任务系统聊天系统怪物系统〔怪物AI、怪物宝石〕道具镶嵌和、改造、合成拜师系统好友系统(结合QQ)AHPLA522建立跨组的游戏调试环境完成神明系统与异常状态的开发完成局部职业的技能(考虑纸娃娃实现,延后进行)进行功能完善:AHPLA622完成界面的改进实现传送系统Server后台功能实现参加修罗城,长乐村等地图AHPLA722DIRSERVER邮件系统寄售系统完善神明及战斗异常状态的画面表现参加神武山迷宫地图参加2张野外地图AHPLA822开店系统职业技能AHPLA922游戏内容、数值调整ClosedBeta版本22测试、BUG修改、完善；ClosedBeta22005年4月第一周2005年4月第四周商业技能〔局部〕怪物属性伤害〔局部〕道具镶嵌与合成〔局部〕任务〔局部〕•ClosedBeta32005年4月第一周2005年5月第四周卡片〔局部〕宠物系统〔不含战斗〕商业技能〔全部〕道具镶嵌和合成〔全部〕新地图黄金城和沙漠迷宫语音聊天功能〔可选〕客户端支持平滑升级〔可选〕任务〔局部〕•OpenBeta2005年4月第一周2005年6月第四周工会系统〔根本功能〕怪物属性伤害〔全部〕支持代理效劳器玩MMOG任务〔局部〕交通飞空艇收费版2005年4月第一周2005年8月第二周宠物系统－战斗〔完成〕半自由PK系统工会系统〔工会战〕任务〔局部〕新地图－新大陆〔可选〕婚姻系统国庆版2005年4月第一周2005年9月第四周全自由PK系统〔预先完成〕攻城战工会飞空艇系统需求系统软件需求SlackwareLinux10.1Kernel2.6.8.1〔支持epoll、iptables〕Cvs版本管理系统Mysql4.0.16Heatbeat1.2.1Libnet1.1.2.1系统硬件需求DB效劳器：DL380G3标配：CPUP42.8G×2内存：1GHPDDRRAM×2硬盘：36G×4RAID5〔100前端效劳器： PT2300标配：CPUP42.4G×2内存：1GDDRRAM×2硬盘：36G×1NORAID日志效劳器：DL380G3标配：CPUP42.8G×2内存：1GHPDDRRAM×2硬盘：146G×4RAID5〔4系统功能需求实时战斗模式，server用2D方式实现，client端可以为2D或者3D沙盘用QQ号码登录游戏，不需单独注册通过QQserver验证，用Kerberos方式实现C/S128bit对称加密用户登录后，可以在一个world的不同地图，不同server自由切换，不需重新连接用户的前端连接和后台server处理逻辑别离，后台server的处理逻辑可以透明更新，不影响在线用户支持后台自动更新。Client端需要更新版本时，用户可以一边玩一边后台更新。当登录用户已经下载好新版本超过一定比例时才要求强行更新〔如大于80%〕server尽可能支持不同版本的client登录。Client在升级失败时可以回退。系统性能需求最小化容量：在一台机器上支持一个完整的world，约5-10万注册用户，1000-2最大化容量：在同一个IDC大区下，支持50万在线用户，划分5-50个world，每个world支持1–20万在线用户。以平均每台机器支撑600-1000用户计算，大概是一个500-8通过简单的配置，可以较方便地实现从最小化到最大化的伸缩考虑到实际情况，可能是在假设干个大的地区，安装200台左右的机器，支持10万-20万在线用户。较小的地区采用更小的规模。响应速度要求：用户登陆时间<5s，在一台1000-200系统总体架构系统物理架构FO采用两个Cluster，多个World的方式。 FO的根本架构是由三层组成：最上一层是Cluster，主要是管理帐号和计费，在一个Cluster中，一个帐号只能登录一次。中间一层是World，主要是管理玩家角色数据，World之间的角色数据是互不相关的，同一个帐号可以在每个World中创立最多三个角色。最下一层是Zone，负责游戏的逻辑，Zone效劳器是用户直接相关的效劳器，属于同一个World的Zone效劳器之间共享角色数据。系统逻辑架构Cluster的逻辑架构图如以下图所示：World、Zone的逻辑架构图如以下图所示：关键技术分析业务模型分析目标用户针对QQ，QQgame的现有用户群18-25岁的年轻用户为主，学生族群为主增加对女性玩家的吸引力，带动男性玩家用户入口QQ梦想客户端桌面入口QQ客户端菜单入口QQgame游戏大厅入偶Gameportal网页入口收费策略会员制，包月用户收费，价格不高于40元人民币会员制，包周用户收费，价格不高于15元人民币虚拟物品贩卖收费，单价0.1Q币~10Q币不等产品依赖关系QQ客户端上的入口及会员标志等多种表现形式QQgame游戏大厅入口，游戏内可进行QQgame的小游戏等与短信、QQ音乐等增殖业务结合增加收入QQ秀，QQ堂等业务推出宣传性道具和地图等内嵌QQ和QQmail发送功能宠物设计与QQ宠物结合一致典型业务过程一个完整的用户登录过程如以下图所示：用户输入帐号和密码，客户端开始连接QQ签名效劳器。QQ签名效劳器根据用户输入的帐号和密码，进行鉴权，并返回签名。客户端连接Dir效劳器，试图获得Zone效劳器的目录列表。Dir效劳器返回当前可用的Zone效劳器列表以及负载信息。用户选择要连接的Zone效劳器，发送连接请求和签名信息。Zone接到请求后，验证该签名，并向World效劳器发送帐号登录请求。World效劳器接收到帐号登录请求后，向Cluster效劳器转发该请求。Cluster效劳器接收到帐号登录请求，记录相应的信息，并向World效劳器返回应答。World效劳器转发该应答到对应的Zone效劳器。Zone效劳器得到应答，进行有关的帐号登录处理，并通知客户端。一个典型的用户操作过程：Client向Zone效劳器发送移动或打斗的操作。Zone效劳器计算出Client移动的新位置或打斗的动作，将它反射给其他Client，使得其他用户可见。Zone效劳器定时将Client操作后的数据同时给World效劳器一个典型的用户查询过程：Client向Zone效劳器发送查询请求。Zone效劳器将此请求发送给World效劳器。World效劳器将查询后的结果返回给Zone效劳器。Zone效劳器将查询结果返回给Client。用户模型分析用户根底信息一个Cluster支持的在线用户为500K一个World支持的在线用户为5000一个Zone支持的在线用户为1500单个用户平均在线时间：1小时/每天在线与注册用户比例：5%活泼与注册用户比例：20%用户操作信息用户登录：按每个Cluster有500K同时在线人数，平均每人每天1小时的在线时长，那么将造成约140次/s登录请求，这样World将有140次/s访问Cluster〔内网访问〕，Cluster将有140次/s访问ClusterDB〔数据库操作〕。按每个World有5000人同时在线人数，平均每人每天1小时的在线时长，那么将造成约1.4次/s登录请求，这样Zone将有1.4次/s访问World〔内网访问〕，World将有1.4/s访问WorldDB〔数据库操作〕。按每个Zone有1500人同时在线人数，平均每人每天1小时的在线时长，那么将造成0.42次/s登录请求，这样Client将有0.42次/s访问Zone〔外网访问〕。用户注销：按每个Cluster有500K同时在线人数，平均每人每天1小时的在线时长，那么将造成约140次/s注销请求，这样World将有140次/s访问Cluster〔外网访问〕，Cluster将有140次/s访问ClusterDB〔数据库操作〕。按每个World有5000人同时在线人数，平均每人每天1小时的在线时长，那么将造成约1.25次/s注销请求，这样Zone将有1.4次/s访问World〔内网访问〕，World将有1.4/s访问WorldDB〔数据库操作〕。按每个Zone有1500人同时在线人数，平均每人每天1小时的在线时长，那么将造成0.42次/s注销请求，这样Client将有0.42次/s访问Zone〔外网访问〕。用户移动〔网络游戏中的角色行走〕：按每个Zone有1500人同时在线人数，平均每人每天1小时在线时长，每人每秒移动1次，每个用户平均被10个其他用户可见，那么造成15K次/s的移动请求，这样Client将有15K次/s访问Zone〔外网访问〕。按每个World有5000人同时在线人数，每3分钟同时一次Zone的数据，那么将造成27次/s同时请求，这样Zone将有27/s访问World〔内网访问〕，World将有25/s访问WorldDB〔数据库操作〕。用户攻击〔网络游戏中的角色打斗〕：按每个Zone有1500人同时在线人数，平均每人每天1小时在线时长，每人每秒攻击1次，每个用户平均被10个其他用户可见，那么造成15K次/s的攻击请求，这样Client将有15K次/s访问Zone〔外网访问〕。Zone与World的同时请求与用户移动的操作同时进行，故不再累计。用户查询〔网络游戏中角色查询货舱等操作〕：按每个Zone有1500人同时在线人数，每10分钟查询一次数据，那么造成2.5次/s查询请求，这样Client将有2.5次/s访问Zone〔外网访问〕。按每个World有5000人同时在线人数，每10分钟查询一次数据，那么造成8.3次/s查询请求，这样Zone将有7.5次/s访问World〔内网访问〕，World将有8.3次/s访问WorldDB〔数据库操作〕。总计：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〔包数〕外网请求用户流量信息用户登录请求流量〔Client－Dir〕：200Bytes用户登录返回流量〔Dir－Client〕：100用户登录请求流量〔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语音流量：15KpsZone切换流量：240Kps系统模型分析ClusterServer Cluster效劳器包括cluster_login和db_process，cluster_login负责与WorldServer交互，并维护OnlineAccountTable，对数据库的访问由db_process负责。WorldServer 一个world可以包含多个zoneserver，每个zoneserver管理一块或者多块地图。一个world最多包括100个zoneserver，每个处理1000-20ZoneserverZone效劳器由zone_connect、zone_disp和zone_server构成。zone_connect负责接收来自客户端的连接，并进行解密，并把消息传递给zone_server进行处理。zone_server负责进行逻辑处理，并根据处理结果或者转给zone_disp并交由其它zone_server进行处理，或者交由World效劳器进行处理。性能容量分析Cluster设备和流量需求Cluster：在线人数：500K注册人数：500K/5%＝10M平均在线时长：1小时公式计算结果备注存储要求注册用户数×单位用户信息10M×100Byte＝1G其中100Byte是单位用户信息带宽要求〔内网〕在线人数×〔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的数据量较小，不会造成数据库的访问瓶颈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带宽要求〔内网〕在线人数×〔登录请求/在线时间＋定时更新/更新频率＋查询请求/查询频率〕×8Bit4500*〔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的数据库操作由于网络包数和数据库操作较少，所有没有瓶颈问题Zone设备和流量需求假定一个Zone支持的最高人数为1500，平均人数为100Zone：在线人数：1500单位用户流量：20Kbps平均在线时长：1小时公式计算结果备注存储要求无带宽要求〔内网〕在线人数×〔登录请求/在线时间＋定时更新/更新频率＋切换Zone/切换频率〕×8Bit1500*〔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带宽要求〔外网〕在线人数×单位用户流量×8Bit1500×2K×8Bit＝24Mbps主要以用户最常使用的操作来进行评估，平均用户每1秒攻击一次，每1秒移动一次，每一个用户平均被10个其他用户可见。10×200Bytes＝2K机器要求1台NRS关键负荷分析30K个/s的数据包30K个/s的数据包将成为数据访问的瓶颈，但由于估算是考虑的是每个人每秒移动并且攻击一次，而且每个人都将给其他10个看到，考虑到并不是所有人都在移动或攻击状态，所以按30％统计，9K个/s的数据包也应该不会对系统造成访问瓶颈杂项设备和流量需求客户端版本检查效劳器客户端版本大小：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.3GbpsWeb效劳器公式计算结果备注存储要求带宽要求〔内网〕带宽要求〔外网〕150Mbps参考?凯旋?，?凯旋?的官网流量约为100MBps。机器要求2台NRS(千兆网卡)＋1台G3关键负荷分析语音效劳器在线人数：500K语音聊天人数：500K×10％＝50K单位语言流量〔一路〕：15Kbps公式计算结果备注存储要求带宽要求〔内网〕带宽要求〔外网〕语音聊天人数×语音流量50K×15K＝725Mbps机器要求3台NRS(千兆网卡)以每台可以支撑的有效负载流量250Mbps来计算关键负荷分析Dir效劳器在线人数：500K平均在线时长：1小时公式计算结果备注存储要求带宽要求〔内网〕带宽要求〔外网〕在线人数×〔Dir返回Client的游戏目录列表〕×8bit500K*〔200+1000Byte〕/3600*8Bit机器要求2台NRS双机热备，1台为主，另一台备份关键负荷分析道具及支付效劳器因为是相比照拟独立的系统，FO8月份开始收费，设备和带宽需求可以在Q3提。Config和Monitor效劳器提供配置和监控，没有外网流量。内网流量很少，可不予考虑。 对于大的Cluster可以考虑使用2台，小的Cluster使用1台。存储要求：无。带宽要求：无。机器要求：NRS，1—2台。Dispatch效劳器Dispatch效劳器用来转发消息和聊天信息。主要的流量在聊天消息和切换Zone消息。在线人数：4500聊天信息：0.5条/sZone切换次数：1次/3分钟公式计算结果备注存储要求带宽要求〔内网〕在线人数×〔聊天信息＋Zone切换信息〕×8bit4500*〔140/2＋30K/180〕*8bit=8.52Mbps带宽要求〔外网〕机器要求1台NRS关键负荷分析包数为2250通信的包数也不是瓶颈Log效劳器Log效劳器主要用来记录玩家的操作，产生玩家的操作流水日志。每两秒产生一次记录。每天游戏时间以12小时计算。在线人数：4500平均在线时长：1小时日志信息：0.5条/s日志保存时间：30天公式计算结果备注存储要求在线人数×日志信息×每天日志条数×日志保存时间4500*140*3600*12*30/2=408.2G带宽要求〔内网〕在线人数×日志信息×8bit4500×140/2×8bit＝2.52Mbps带宽要求〔外网〕机器要求G3，4×136GB硬盘，1台关键负荷分析包数为2250流量带宽不是瓶颈，通信的包数也不是瓶颈总计一个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的总计：带宽要求〔内网〕为：0.22Mbps〔World－Cluster〕＝0.22Mbps带宽要求〔外网〕为：1.33Mbps〔Client－Dir〕＋0.67Gbps〔下载〕＋150Mbps〔Web〕＋725Mbps〔语音〕＝1.56Gbps设备需求：NRS：2(Dir)+1(Config)+1(Web)+2(Voice)+1(Moniter)+2〔版本检查〕+3〔千兆下载，或者12台百兆下载〕+1〔QQ验证〕=13〔台〕G3：1〔Cluster〕*2+1〔WebDB〕= 3〔台〕负载均衡分析负载均衡策略FO的负载均衡以增加新的World作为负载均衡的主要手段。每一个World是一个相对独立的局部，可以支撑玩家在其中进行游戏。World的增加，会导致Cluster的负载增加，由于Cluster与World的交互很少，因此对Cluster的影响较小。当随着World的增加导致Cluster的负载太大，单台效劳器不能承受的时候，可以考虑对Cluster进行分布，每个Cluster仅为指定QQ号段效劳，这样可以实现Cluster的负载均衡。异地分布策略FO的异地分布策略主要是如下两条：FO是否在某个城市进行分布和分布的数量，是根据该城市潜在的游戏用户数来确定，潜在用户数多，那么分布的World多，否那么分布的就少。覆盖度原那么，每在一个城市进行分布，那么除了可以为该城市的游戏用户进行效劳，也可以为相邻的一些城市提供效劳。在进行分布的时候，遵循的原那么是：使用尽可能少的分布点来到达尽可能大的覆盖度。容灾备份分析对于游戏运营，最重要的就是用户数据，因此所有的手段都是围绕一个目的，即保证用户的数据不出现问题。为了保证极端情况下，尽可能的减少用户数据的损失，数据备份是一个很重要的手段。 按照内测的数据，7MByte的存储，12320个角色，平均每个角色的存储为6按照每个角色根本数据的最大值来计算，每个角色的根本数据为30K： 30K(单一角色存储)*90K〔最高在线人数〕*10(角色数与最高在线人数比) = 27G〔Byte〕那么保存30天的数据量为： 27G*30 = 840G因为上述值是按照最保守的方式来计算的，实际的数据量应不超过上述计算值的一半，如果再加上压缩，那么实际的存储应不超过200目前FO的备份方案是：分南北两个Cluster各自使用一个磁盘柜进行备份，备份的方式是采用全量备份，每天进行一次备份，备份时间为1~2个月〔视具体情况而定〕。如果有条件的话，还可以考虑使用磁带机进行备份，每周全量备份一次。部署方案 目前FO的IDC分布规划如以下图所示： 分为南方和北方两个Cluster〔分别针对不同的运营商：电信和网通〕。 每个大区下面根据需要有不同的World。 每个world预计承载4500人，由三台效劳器共同提供效劳，单台效劳器的负载在1500人左右。 每个玩家的流量为15-20kbps。风险分析及躲避措施总的来讲，FO运营的风险可以分成硬件故障和软件故障两大类。硬件的故障包括机器的故障、磁盘故障、IDC线路故障，黑客攻击等。 软件的故障包括数据库失效、程序失效等等。硬件故障针对不同的硬件故障，提供不同的应对策略。机器、磁盘故障对于机器或者磁盘故障的应对方式有两种：主动方式：对运行一些重要应用的机器提供HA方案，双机热备，当其中一台失效的时候，由另一台接管其工作。采用这种方式，可以把故障的处理时间降到10-20分钟。在另一台机器接管工作之后，再对故障机器进行检查，根据具体情况或更换、或修理。在失效机器恢复正常之后，失效机器以备机的身份重新开始效劳。被动方式：对于运行不重要应用的机器提供快速更换效劳。快速更换效劳指的是机器上的应用和配置都已准备好，当出现故障，需要更换其它机器时，只要对该效劳器稍作修改就可以代替故障机器。 FO采取的措施是两者皆用，一方面在每个IDC机房内准备一些备用机器，另一方面对关系到用户数据的机器提供HA方案。 具体的方式是：每个IDC视支撑人数的大小，确定备用机器的数量和种类。对于小的IDC，保存2台备用机，1台为数据库备用机，1台为前端备用机。大的IDC，保存4台备用机，2台数据库，2台前端。对于Cluster〔账号和计费〕效劳器和World〔角色〕效劳器提供HA方案，保证用户的数据可以很快恢复访问。IDC线路故障和黑客攻击对于IDC线路故障和黑客攻击，这个没有方法完全防止问题，只能是尽量减少损失。应对的措施主要是进行IDC分布，当一个IDC出现问题的时候，不会影响到另一个IDC的玩家。FO采用两个Cluster，多个World的方式。如果Cluster正常，只是World出现问题，那么受影响的只是出问题的World的玩家。如果Cluster出现问题，World正常，由于World和Cluster只在用户登入、登出和某些特殊的事件进行通信，那么已经登入的用户还是可以继续游戏，但是新用户将不能登陆。所有开放内网监听端口的应用程序都采用了限制IP的机制，报障了只有内部IP可以访问。所有开发外网监听端口的应用程序采用了超时限制和包大小限制来报障黑客的拒绝效劳攻击，此外对于与外网的通信协议采用了加密算法，防止黑客的探测攻击。软件故障Dir效劳器 Dir效劳器是客户端拉取游戏分区信息的效劳器，是用户进行游戏的第一个入口。一个Dir效劳器为一个cluster效劳，如果Dir效劳器出现故障，会对用户的登陆产生严重的影响。由于Dir效劳器不保存任何数据，可以说是没有状态的。因此Dir效劳器可以采用对称多处理的方式。Dir效劳器的信息来源是Zone效劳器上报的信息，为了提供容错，Zone效劳器将向两个Dir效劳器同时上报同样的信息，这样在两个Dir效劳器中产生完全相同的两份数据，当其中一台Dir效劳器失效的时候，另一台可以继续提供效劳。在客户端可以提供一个访问策略，先随即选择一台Dir效劳器，如果该效劳器不能提供效劳，再选择另一台Dir效劳器。 对于可伸缩性的考虑。由于Dir效劳器是为Cluster效劳的，因此，Dir效劳器的负载变动的范围可能会比较大。采用两个Dir效劳器对称处理的方式提供了高可用性，也提高了一倍的负载能力，但是还是可能会出现负载过大的情况。如果两台Dir效劳器不能满足效劳器的需要，那么可以考虑复制