腾讯游戏后台架构及开发介绍

QQGame后台架构及开发介绍AgendaI.整体结构框架II.业务模块介绍III.海量用户的运营IV.在现实中挣扎QQGame后台？全球最大的休闲游戏平台3亿2千万用户，400万人同时在线比魔兽世界更出色的系统架构为无数程序员所景仰整体框架图关键业务模块辅助业务模块游戏秀系统聊天系统道具系统宝宝系统商城和付费模块好友功能家族系统反外挂系统营销消息系统RTI对外服务游戏秀——存储16台AvatarDBSvr存储了1亿多用户的游戏秀资料。游戏心语、自定义性别和昵称、地区星座职业等内容也是游戏秀资料的一部分。衣服只是一个ID而已。游戏秀——两个交互途径如何看到自己的游戏秀——个人资料服务器登录时拉取如何看到其他人的游戏秀——进房同步数据下发和房间事件下发，或者客户端主动请求。游戏秀——非实时更新为什么需要重新登录大厅才能看到自己的游戏秀改变？大厅只在登录的时候拉取一次自己的游戏秀，如果游戏秀在大厅不知道的情况下发生了变动，就只能重新登录才能看到变动。道具商城购买、物品栏保存形象、创建角色秀等不用重新登录大厅。聊天系统——多样化小喇叭——QQ游戏虚拟世界中的硬通货。烟花——很贵很漂亮。房间内聊天——穷人的小广告游戏桌内聊天——边玩边聊聊天系统——拓扑结构拓扑结构聊天系统——脏语过滤过滤对象：政治性敏感词汇、色情类词汇、虚假消息。过滤结果：马赛克、丢弃、拉黑。过滤方式：字符串匹配。聊天系统——打击与人斗其乐无穷先币后款，加449899634先B后款，加449899634先比后款，加449899634先*后*[0-9]*你已中奖你已中浆你已中桨zhongjiang商城系统拓扑结构商城系统——业务流程商城服务器、商品配置下载服务器、支付QQAccountProxySvr处理时序：1.处理购买请求2.合法性检查3.批价扣费4.发货商城系统——故障无法打开：1.无法下载商城布局资源。2.无法拉取个人资料信息。道具被刷：1.扣钱失败，发货却成功。2.利用溢出，花少量的钱购买大量的商品。小喇叭一个8000游戏币，破解客户端一次购买了536871个小喇叭，价格是8000*536871=4294968000（溢出）。使得用户只花费了704个游戏币。好友和家族系统接入和逻辑：单独的好友和家族前端服务器存储：好友DBSvr和家族DBSvr反外挂系统外挂的类型：crack、模拟器。基于“计算、应答”模式的反外挂系统。客户端在规定的时间内必须回答MainSvr一个正确的计算值。反外挂系统是MainSvr的一部分，计算逻辑剥离成单独的进程，MainSvr进程只负责数据转发。营销消息系统没有营销消息的系统不能算平台。QQGame需要怎样的营销消息？用途广泛：•登录提示•进房提示•房间内滚动•定向（按号码、按游戏、按房间、按座位）发送使用方便：•谁都可以发•可以自动发营销消息---------拓扑结构营销消息——陆海空投放RTI——RunTimeInfrastructure产品的大部分需求：1.用户做了XX事情的时候，给用户一个XX提示。2.用户的XX属性发生变化的时候，给用户一个XX提示。3.用户做了XX事情的时候，修改用户的XX属性值。需求总结如下：游戏系统产生的事件，在游戏系统外部加工后反馈给游戏系统，并影响游戏的逻辑。•事件必须是游戏逻辑本身已经存在的。•游戏系统能接受该反馈的输入指令。RTI——拓扑结构RTI本质是一个数据分发器游戏逻辑OutPutRTI产品需求1产品需求2产品需求3OutPutOutPutOutPut外部输入接口Logic1Logic2Logic3Logic1Logic2Logic3ClientRTI——拓扑结构RTI本质是一个数据分发器RTI——应用实例宝宝系统对外服务AccountSvr为外部应用（主要是web）提供以下服务1.加减游戏币2.加减欢乐豆3.家族操作4.用户信息查询5.道具和Avatar赠送核心业务模块业务系统的三层框架模型负载均衡的dir统一的中心配置管理策略大容量的接入服务器无缝插接游戏的MainSvr带路由功能的数据交换机存储海量用户的数据库业务系统的三层框架接入层逻辑层中转层存储层负责网络接入负责游戏逻辑负责数据转发负责数据存储目录树系统——负载均衡用户的最终目标，是Login游戏服务器进行娱乐。400万同时在线，如何分流这些用户到不同的游戏服务器上？目录树服务器——DirSvr目录树系统19台DirSvr服务器提供导航树的下载、游戏服务器列表的下载、大厅配置文件的下载。中心配置策略大容量接入服务器游戏服务器面临的问题：1.大数据量快速交互2.海量并发数下的响应解决之道：1.接入与逻辑分离的进程模型2.采用Epoll模型3.接入层和逻辑层之间采用共享内存高速通信MainSvr进程模型MainSvrTCPSvrPIPEINPIPEOUTAUXThread1AUXThread2CtrlCtrlDataData无缝插接游戏MainSvrRoom0Room1Room2Zq.soDdzrpg.soDdzrpg.so基于房间的游戏调度每个MainSvr进程可以开设60个游戏房间每个游戏都能部署在任意房间里房间数能够根据游戏运营情况动态调整数据交换机TCPProxySvr逻辑层和存储层之间的数据交换机和路由器使得逻辑层和存储层在部署层面上解耦合沙漏型结构，便于管理多种路由方式选择：点对点、Key转发、组播和广播Proxy本身无状态无存储，便于扩展TCPProxySvr的路由表路由表K1K2KNC1C1CNKeyDB1DB2DBNDataAnalysis海量存储GameDBSvr同时在线：400万活跃用户数：2000万注册用户数：3亿2千万大量的并发游戏币、欢乐豆、游戏积分和游戏数据的更改及查询GameDBSvr进程模型主控线程处理线程1MySQL数据表1处理线程2MySQL数据表2处理线程3MySQL数据表3处理线程4MySQL数据表4处理线程5MySQL数据表5……………………处理线程16MySQL数据表16GameDBSvr的性能大容量Cache：99%的命中率，直接减少读IO。多线程处理：逻辑处理和数据库IO分开，提高吞吐率。数据库调优：Innodb引擎，禁止自动提交事务。分布的数据中心64台GameDBSvr，本地存储数据按号段存储groupkey=（UIN16）%256通过TCPProxySvr全连接所有的MainSvr存储层的树状扩展模型DB0DB0DB1DB0DB2DB1DB3。。。。。。。。。DB的分裂方式继承和数据迁移主从数据同步，统一切割III.海量用户下的运营能力面对持续增长的用户压力，如何处理？——扩容面对突发的请求量和业务暴涨，如何应对？——防过载面对日益恶化的互联网环境，如何保持用户体验？——多IDC部署如果深圳地震了，是否能够继续运营？——设备冗余持续的扩容能力业务逻辑要能支持无限扩容存储无关模块的快速扩容存储模块的有序扩容不做无准备扩容对系统负荷和容量有深刻的认识系统的短板效应时刻关注系统状况平滑扩容对用户和其他模块透明动态和灰度扩容过载保护——雪崩系统的性能与负载曲线0100200300400500600700800900010020030040050060070080090010001100120013001400请求数响应数系统1系统2雪崩的原因用户的行为无法控制1.反复登录2.疯狂刷新页面系统的高度耦合性使得模块之间互相依赖1.多米诺骨牌效应2.单点故障效应曾经的案例Dir请求数过多，导致系统雪崩，中断服务8小时。奥运门票销售第一天，中国银行网点全部崩溃。CGX事件导致QQ.com服务崩溃。防止雪崩深刻了解系统的瓶颈限定系统处理能力20%的崩溃不应该影响80%的用户优先保证重点用户的服务接入现状——问题电信网通互访困难长途链路很不稳定特定路由无法连通单IDC难以覆盖全球用户马甲100:08:41呵呵，不好意思，因为全球各个国家地区到我们各个机房的网络质量都不一样，我们只能通过多个机房部署来尽量满足大家的需要欧洲用户00:09:23我知道，我问过匈牙利的哥哥，他说他一点也不卡，但是英国和爱尔兰就和我的情况一样欧洲用户00:09:41意大利的蒜蒜一定和我一样，欧洲用户00:09:58晚上我问问西班牙和奥地利的看看欧洲用户00:16:12这俩天我晚上在家都不能打牌，10点就睡觉了，睡的头都疼死了，也是你们的责任原因——运营商三大门派：南电信，北网通，教育科研网。绝大部分的电信玩家，蓬勃发展的网通用户，无法忽略的教育网。三教九流：铁通、长城宽带、天威有线……重组之后：中移动、联通、电信三分天下。原因——基础设施两大运营商各自建设自己的骨干网。带宽不断被吞噬，P2P是万恶之首。迎奥运，电信9扩，网通5扩。曾经的西安电信26F西北华北东北西南华东华南西安电信26F多IDC部署西安上海天津深圳多IDC的精细化运营基于地区、特定用户诉求。重点游戏全国分布。网络质量随时监控，游戏房间动态调整。玩家就近接入，提升用户体验。如何应对灾难？9.11给我们的启示汶川地震，西安IDC受到影响如果深圳地震了。。。深圳IDC现状一半MainSvr部署在深圳（枢纽、龙岗、沙河、中深网通）一半的dirsvr部署在深圳（绝大部分在枢纽）几乎所有用户资料存放在深圳（沙河）深圳的灭顶之灾==QQGame的世界末日努力活下去吧。。。QQGame的容灾能力数据容灾——异地备份1.64台GameDBSvr主机（沙河）+64台GameDBSvr备机（西安）2.16台AvatarDBSvr主从备份3.其余设备冷备份前端容灾——设备冗余和快速部署能力1.多IDC冗余分布2.各种前端逻辑快速切换到其他IDC容一个IDC的灾难西安IDC故障：断电断网1.DB类服务切备机2.关停非重要类游戏3.重要类游戏快速迁往其他IDC的空闲机IV.在现实中挣扎一个复杂的系统，如何应对各种故障？一个庞大的需求，如何进行开发？进度排不过来，产品和策划该怎么办？新业务上线，频繁出现问题。大规模设备升级＝＝无休止的加班。系统解耦合——抗风险一个大灯泡和十个小灯泡的亮度是一样的，抗风险能力却不同QQGame可以分拆成多个系统模块单一模块的故障不影响整个系统的服务非０即１不是我们的选择。大需求化小——多次迭代化整为零：需求是可以分解为多个小特性的。多次迭代：每次专注于一个小特性的开发。频繁构建：自动化测试保证代码质量。分期上线——解决资源冲突当产品需求和开发资源冲突时怎么办？当时间无法保证系统完整上线时怎么办？买房可以分期付款，需求也可以分批交付。还是不要非０即１的选择。开发和运维人员的现状大部分的加班都是由于版本回退造成的新业务的发布没有不出问题切割时提心吊胆，内分泌失调灰度升级——０和１之外的选择开发不是圣人，测试不是神仙，新版本出问题是必然的，不出问题是偶然的。小概率问题能在海量用户前暴露新业务一定要灰度升级一定要做到真正的灰度客户端的灰度发布：控制放量Svr的灰度发布：随机、按号段、按大区。Svr和客户端同时灰度发布：1.Svr要能做到新老版本的兼容2.客户端也要做到新老版本的兼容3.隔离新老版本的访问，新版本svr出现的问题只影响新版本的客户端Q&A