游戏后台架构及开发介绍培训课件

《游戏后台架构及开发介绍培训课件》由会员分享，可在线阅读，更多相关《游戏后台架构及开发介绍培训课件（70页珍藏版）》请在金锄头文库上搜索。

1、QQGame后台架构及开发介绍,Agenda,整体结构框架 业务模块介绍 海量用户的运营 在现实中挣扎,QQGame后台？,全球最大的休闲游戏平台 3亿2千万用户，400万人同时在线 比魔兽世界更出色的系统架构 为无数程序员所景仰,整体框架图,辅助业务模块,游戏秀系统 聊天系统 道具系统 宝宝系统 商城和付费模块 好友功能 家族系统 反外挂系统 营销消息系统 RTI 对外服务,游戏秀 存储,16台AvatarDBSvr存储了1亿多用户的游戏秀资料。 游戏心语、自定义性别和昵称、地区星座职业等内容也是游戏秀资料的一部分。 衣服只是一个ID而已。,游戏秀 两个交互途径,如何看到自己的游戏秀 个人资

2、料服务器登录时拉取 如何看到其他人的游戏秀 进房同步数据下发和房间事件下发，或者客户端主动请求。,游戏秀 非实时更新,为什么需要重新登录大厅才能看到自己的游戏秀改变？ 大厅只在登录的时候拉取一次自己的游戏秀，如果游戏秀在大厅不知道的情况下发生了变动，就只能重新登录才能看到变动。 道具商城购买、物品栏保存形象、创建角色秀等不用重新登录大厅。,聊天系统 多样化,小喇叭 QQ游戏虚拟世界中的硬通货。 烟花 很贵很漂亮。 房间内聊天 穷人的小广告 游戏桌内聊天 边玩边聊,聊天系统 拓扑结构,拓扑结构,聊天系统 脏语过滤,过滤对象：政治性敏感词汇、色情类词汇、虚假消息。 过滤结果：马赛克、 丢弃、拉黑。

3、 过滤方式：字符串匹配。,聊天系统 打击,与人斗其乐无穷,zhongjiang,商城系统,拓扑结构,商城系统 业务流程,商城服务器、商品配置下载服务器、 支付QQAccountProxySvr 处理时序： 1. 处理购买请求 2. 合法性检查 3. 批价扣费 4. 发货,商城系统 故障,无法打开： 1. 无法下载商城布局资源。 2. 无法拉取个人资料信息。 道具被刷： 1. 扣钱失败，发货却成功。 2. 利用溢出，花少量的钱购买大量的商品。 小喇叭一个8000游戏币，破解客户端一次购买了536871个小喇叭，价格是8000*536871=4294968000（溢出）。使得用户只花费了704个游

4、戏币。,好友和家族系统,接入和逻辑：单独的好友和家族前端服务器 存储：好友DBSvr和家族DBSvr,反外挂系统,外挂的类型：crack、模拟器。 基于“计算、应答”模式的反外挂系统。客户端在规定的时间内必须回答MainSvr一个正确的计算值。 反外挂系统是MainSvr的一部分，计算逻辑剥离成单独的进程，MainSvr进程只负责数据转发。,营销消息系统,没有营销消息的系统不能算平台。 QQGame需要怎样的营销消息？,用途广泛： 登录提示 进房提示 房间内滚动 定向（按号码、按游戏、按房间、按座位）发送,使用方便： 谁都可以发 可以自动发,营销消息 - 拓扑结构,营销消息 陆海空投放,RTI

5、 Run Time Infrastructure,产品的大部分需求： 用户做了XX事情的时候，给用户一个XX提示。 用户的XX属性发生变化的时候，给用户一个XX提示。 用户做了XX事情的时候，修改用户的XX属性值。 需求总结如下： 游戏系统产生的事件，在游戏系统外部加工后反馈给游戏系统，并影响游戏的逻辑。 事件必须是游戏逻辑本身已经存在的。 游戏系统能接受该反馈的输入指令。,RTI 拓扑结构,RTI本质是一个数据分发器,RTI 拓扑结构,RTI本质是一个数据分发器,RTI 应用实例,宝宝系统,对外服务,AccountSvr为外部应用（主要是web）提供以下服务 1. 加减游戏币 2. 加减欢乐

6、豆 3. 家族操作 4. 用户信息查询 5. 道具和Avatar赠送,核心业务模块,业务系统的三层框架模型 负载均衡的dir 统一的中心配置管理策略 大容量的接入服务器 无缝插接游戏的MainSvr 带路由功能的数据交换机 存储海量用户的数据库,业务系统的三层框架,负责网络接入,负责游戏逻辑,负责数据转发,负责数据存储,目录树系统 负载均衡,用户的最终目标，是Login游戏服务器进行娱乐。 400万同时在线，如何分流这些用户到不同的游戏服务器上？ 目录树服务器 DirSvr,目录树系统,19台DirSvr服务器提供导航树的下载、游戏服务器列表的下载、大厅配置文件的下载。,中心配置策略,大容量接

7、入服务器,游戏服务器面临的问题： 大数据量快速交互 海量并发数下的响应 解决之道： 接入与逻辑分离的进程模型 采用Epoll模型 接入层和逻辑层之间采用共享内存高速通信,MainSvr进程模型,MainSvr,TCPSvr,PIPE IN,PIPE OUT,AUX Thread1,AUX Thread2,Ctrl,Ctrl,Data,Data,无缝插接游戏,MainSvr,Room 0,Room 1,Room 2,Zq.so,Ddzrpg.so,Ddzrpg.so,基于房间的游戏调度,每个MainSvr进程可以开设60个游戏房间 每个游戏都能部署在任意房间里 房间数能够根据游戏运营情况动态调整

8、,数据交换机TCPProxySvr,逻辑层和存储层之间的数据交换机和路由器 使得逻辑层和存储层在部署层面上解耦合 沙漏型结构，便于管理 多种路由方式选择：点对点、Key转发、组播和广播 Proxy本身无状态无存储，便于扩展,TCPProxySvr的路由表,海量存储GameDBSvr,同时在线：400万 活跃用户数：2000万 注册用户数：3亿2千万 大量的并发游戏币、欢乐豆、游戏积分和游戏数据的更改及查询,GameDBSvr进程模型,GameDBSvr的性能,大容量Cache：99%的命中率，直接减少读IO。 多线程处理：逻辑处理和数据库IO分开，提高吞吐率。 数据库调优：Innodb引擎，禁

9、止自动提交事务。,分布的数据中心,64台GameDBSvr，本地存储数据 按号段存储 group key = （UIN16）%256 通过TCPProxySvr全连接所有的MainSvr,存储层的树状扩展模型,DB0,DB0,DB1,DB0,DB2,DB1,DB3,。,DB的分裂方式,继承和数据迁移 主从数据同步，统一切割,III. 海量用户下的运营能力,面对持续增长的用户压力，如何处理？扩容 面对突发的请求量和业务暴涨，如何应对？ 防过载 面对日益恶化的互联网环境，如何保持用户体验？ 多IDC部署 如果深圳地震了，是否能够继续运营？ 设备冗余,持续的扩容能力,业务逻辑要能支持无限扩容 存储无

10、关模块的快速扩容 存储模块的有序扩容,不做无准备扩容,对系统负荷和容量有深刻的认识 系统的短板效应 时刻关注系统状况,平滑扩容,对用户和其他模块透明 动态和灰度扩容,过载保护 雪崩,系统的性能与负载曲线,雪崩的原因,用户的行为无法控制 反复登录 疯狂刷新页面 系统的高度耦合性使得模块之间互相依赖 多米诺骨牌效应 单点故障效应,曾经的案例,Dir请求数过多，导致系统雪崩，中断服务8小时。 奥运门票销售第一天，中国银行网点全部崩溃。 CGX事件导致QQ.com服务崩溃。,防止雪崩,深刻了解系统的瓶颈 限定系统处理能力 20%的崩溃不应该影响80%的用户 优先保证重点用户的服务,接入现状 问题,电信

11、网通互访困难 长途链路很不稳定 特定路由无法连通 单IDC难以覆盖全球用户,马甲1 00:08:41 呵呵，不好意思，因为全球各个国家地区到我们各个机房的网络质量都不一样，我们只能通过多个机房部署来尽量满足大家的需要 欧洲用户 00:09:23 我知道，我问过匈牙利的哥哥，他说他一点也不卡，但是英国和爱尔兰就和我的情况一样 欧洲用户 00:09:41 意大利的蒜蒜一定和我一样， 欧洲用户 00:09:58 晚上我问问西班牙和奥地利的看看 欧洲用户 00:16:12 这俩天我晚上在家都不能打牌，10点就睡觉了，睡的头都疼死了，也是你们的责任,原因 运营商,三大门派： 南电信，北网通，教育科研网。

12、 绝大部分的电信玩家，蓬勃发展的网通用户，无法忽略的教育网。 三教九流： 铁通、长城宽带、天威有线 重组之后： 中移动、联通、电信三分天下。,原因 基础设施,两大运营商各自建设自己的骨干网。 带宽不断被吞噬，P2P是万恶之首。 迎奥运，电信9扩，网通5扩。,曾经的西安电信26F,西北,华北东北,西南,华东华南,西安电信26F,多IDC部署,西安,上海,天津,深圳,多IDC的精细化运营,基于地区、特定用户诉求。 重点游戏全国分布。 网络质量随时监控，游戏房间动态调整。 玩家就近接入，提升用户体验。,如何应对灾难？,9.11 给我们的启示 汶川地震，西安IDC受到影响 如果深圳地震了。,深圳IDC

13、现状,一半MainSvr部署在深圳（枢纽、龙岗、沙河、中深网通） 一半的dirsvr部署在深圳（绝大部分在枢纽） 几乎所有用户资料存放在深圳（沙河） 深圳的灭顶之灾 = QQGame的世界末日,努力活下去吧。,QQGame的容灾能力,数据容灾 异地备份 64台GameDBSvr主机（沙河） + 64台GameDBSvr备机（西安） 16台AvatarDBSvr主从备份 其余设备冷备份 前端容灾 设备冗余和快速部署能力 多IDC冗余分布 各种前端逻辑快速切换到其他IDC,容一个IDC的灾难,西安IDC故障：断电断网 DB类服务切备机 关停非重要类游戏 重要类游戏快速迁往其他IDC的空闲机,IV.

14、 在现实中挣扎,一个复杂的系统，如何应对各种故障？ 一个庞大的需求，如何进行开发？ 进度排不过来，产品和策划该怎么办？ 新业务上线，频繁出现问题。 大规模设备升级无休止的加班。,系统解耦合 抗风险,一个大灯泡和十个小灯泡的亮度是一样的，抗风险能力却不同 QQGame可以分拆成多个系统模块 单一模块的故障不影响整个系统的服务 非即不是我们的选择。,大需求化小 多次迭代,化整为零：需求是可以分解为多个小特性的。 多次迭代：每次专注于一个小特性的开发。 频繁构建： 自动化测试保证代码质量。,分期上线 解决资源冲突,当产品需求和开发资源冲突时怎么办？ 当时间无法保证系统完整上线时怎么办？ 买房可以分期付款，需求也可以分批交付。 还是不要非即的选择。,开发和运维人员的现状,大部分的加班都是由于版本回退造成的 新业务的发布没有不出问题 切割时提心吊胆，内分泌失调,灰度升级 和之外的选择,开发不是圣人，测试不是神仙，新版本出问题是必然的，不出问题是偶然的。 小概率问题能在海量用户前暴露 新业务一定要灰度升级,一定要做到真正的灰度,客户端的灰度发布：控制放量 Svr的灰度发布：随机、按号段、按大区。 Svr和客户端同时灰度发布： Svr要能做到新老版本的兼容 客户端也要做到新老版本的兼容 隔离新老版本的访问，新版本svr出现的问题只影响新版本的客户端,Q & A,