互联网公司技术架构资料.腾讯.QQGame后台架构

QQGame后台架构及开发介绍Agenda 整体结构框架 业务模块介绍 海量用户的运营 在现实中挣扎QQGame后台？! 全球最大的休闲游戏平台! 3亿2千万用户，400万人同时在线! 比魔兽世界更出色的系统架构! 为无数程序员所景仰整体框架图关键业务模块辅助业务模块! 游戏秀系统! 聊天系统! 道具系统! 宝宝系统! 商城和付费模块! 好友功能! 家族系统! 反外挂系统! 营销消息系统! RTI! 对外服务游戏秀存储! 16台AvatarDBSvr存储了1亿多用户的游戏秀资料。! 游戏心语、自定义性别和昵称、地区星座职业等内容也是游戏秀资料的一部分。! 衣服只是一个ID而已。游戏秀两个交互途径! 如何看到自己的游戏秀个人资料服务器登录时拉取! 如何看到其他人的游戏秀进房同步数据下发和房间事件下发，或者客户端主动请求。游戏秀非实时更新! 为什么需要重新登录大厅才能看到自己的游戏秀改变？! 大厅只在登录的时候拉取一次自己的游戏秀，如果游戏秀在大厅不知道的情况下发生了变动，就只能重新登录才能看到变动。! 道具商城购买、物品栏保存形象、创建角色秀等不用重新登录大厅。聊天系统多样化! 小喇叭QQ游戏虚拟世界中的硬通货。! 烟花很贵很漂亮。! 房间内聊天穷人的小广告! 游戏桌内聊天边玩边聊聊天系统拓扑结构! 拓扑结构聊天系统脏语过滤! 过滤对象：政治性敏感词汇、色情类词汇、虚假消息。! 过滤结果：马赛克、丢弃、拉黑。! 过滤方式：字符串匹配。聊天系统打击! 与人斗其乐无穷449899634B449899634449899634**[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需要怎样的营销消息？用途广泛：• 登录提示• 进房提示• 房间内滚动• 定向（按号码、按游戏、按房间、按座位）发送使用方便：• 谁都可以发• 可以自动发营销消息---------拓扑结构营销消息陆海空投放RTIRunTimeInfrastructure! 产品的大部分需求：1. 用户做了XX事情的时候，给用户一个XX提示。2. 用户的XX属性发生变化的时候，给用户一个XX提示。3. 用户做了XX事情的时候，修改用户的XX属性值。! 需求总结如下：游戏系统产生的事件，在游戏系统外部加工后反馈给游戏系统，并影响游戏的逻辑。• 事件必须是游戏逻辑本身已经存在的。• 游戏系统能接受该反馈的输入指令。RTI拓扑结构! RTI本质是一个数据分发器OutPutRTI123OutPutOutPutOutPutLogic1Logic2Logic3Logic1Logic2Logic3ClientRTI拓扑结构! 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存储层的树状扩展模型DB0DB0DB1DB0DB2DB1DB3DB的分裂方式! 继承和数据迁移! 主从数据同步，统一切割III.海量用户下的运营能力! 面对持续增长的用户压力，如何处理？扩容! 面对突发的请求量和业务暴涨，如何应对？防过载! 面对日益恶化的互联网环境，如何保持用户体验？多IDC部署! 如果深圳地震了，是否能够继续运营？设备冗余持续的扩容能力! 业务逻辑要能支持无限扩容! 存储无关模块的快速扩容! 存储模块的有序扩容不做无准备扩容! 对系统负荷和容量有深刻的认识! 系统的短板效应! 时刻关注系统状况平滑扩容! 对用户和其他模块透明! 动态和灰度扩容过载保护　雪崩! 系统的性能与负载曲线雪崩的原因! 用户的行为无法控制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