概要信息：

QQGame后台架构及开发介绍 

Agenda 
  整体结构框架 
  业务模块介绍 
  海量用户的运营 
  在现实中挣扎 
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  Run Time Infrastructure 
!   产品的大部分需求： 
1.   用户做了XX事情的时候，给用户一个XX提示。 
2.   用户的XX属性发生变化的时候，给用户一个XX提示。 
3.   用户做了XX事情的时候，修改用户的XX属性值。 
!   需求总结如下： 
           游戏系统产生的事件，在游戏系统外部加工后反
馈给游戏系统，并影响游戏的逻辑。 
•   事件必须是游戏逻辑本身已经存在的。 
•   游戏系统能接受该反馈的输入指令。 
RTI  拓扑结构 
!   RTI本质是一个数据分发器 
	

O
utPut
RTI

1

2

3
OutPut
OutPut
OutPut


Lo
gic
 1
Lo
gi
c2
Lo
gi
c3
Logic1
Logic2
Logic3
Client
RTI  拓扑结构 
!   RTI本质是一个数据分发器 
RTI  应用实例 
!  宝宝系统 
 
 
对外服务 
!  AccountSvr为外部应用（主要是web）提供以下服
务 
 1.  加减游戏币 
 2.  加减欢乐豆 
 3.  家族操作 
 4.  用户信息查询 
 5.  道具和Avatar赠送 
核心业务模块 
!  业务系统的三层框架模型 
!  负载均衡的dir 
!  统一的中心配置管理策略 
!  大容量的接入服务器 
!  无缝插接游戏的MainSvr 
!  带路由功能的数据交换机 
!  存储海量用户的数据库 
业务系统的三层框架 

	



负责网络接入 
负责游戏逻辑 
负责数据转发 
负责数据存储 
目录树系统 
负载均衡 
!  用户的最终目标，是Login游戏服务器进行娱乐。 
!  400万同时在线，如何分流这些用户到不同的游
戏服务器上？ 
!  目录树服务器  DirSvr 
目录树系统 
!   19台DirSvr服务器提供导航树的下载、游戏服务器
列表的下载、大厅配置文件的下载。 
中心配置策略 
大容量接入服务器 
!   游戏服务器面临的问题： 
1. 大数据量快速交互 
2.   海量并发数下的响应 
!   解决之道： 
1.   接入与逻辑分离的进程模型  
2.   采用Epoll模型 
3.   接入层和逻辑层之间采用共享内存高速通信 
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个游戏房间 
!  每个游戏都能部署在任意房间里 
!  房间数能够根据游戏运营情况动态调整 
数据交换机TCPProxySvr 
!  逻辑层和存储层之间的数据交换机和路由器 
!  使得逻辑层和存储层在部署层面上解耦合 
!  沙漏型结构，便于管理 
!  多种路由方式选择：点对点、Key转发、组播和广
播 
!  Proxy本身无状态无存储，便于扩展 
TCPProxySvr的路由表 
路由表 
K1 
K2 
KN 
C1 
C1 
CN 
Key 
 
DB1 
DB2 
DBN 
Data 
Analysis 
海量存储GameDBSvr 
!  同时在线：400万 
!  活跃用户数：2000万 
!  注册用户数：3亿2千万 
!  大量的并发游戏币、欢乐豆、游戏积分和游戏数
据的更改及查询 
GameDBSvr进程模型 
主控线程 
处理
线程
1 
MySQL
数据
表1 
处理
线程
2 
MySQL
数据
表2 
处理
线程
3 
MySQL
数据
表3 
处理
线程
4 
MySQL
数据
表4 
处理
线程
5 
MySQL
数据
表5 
…… 
…… 
…… 
…… 
处理
线程
16 
MySQL
数据
表16 
GameDBSvr的性能 
!  大容量Cache：99%的命中率，直接减少读IO。 
!  多线程处理：逻辑处理和数据库IO分开，提高吞
吐率。 
!  数据库调优：Innodb引擎，禁止自动提交事务。 
分布的数据中心 
!  64台GameDBSvr，本地存储数据 
!  按号段存储  group key  = （UIN>>16）%256    
!  通过TCPProxySvr全连接所有的MainSvr 
存储层的树状扩展模型 
DB0 
DB0 DB1 
DB0 DB2 DB1 DB3 


DB的分裂方式 
!  继承和数据迁移 
!  主从数据同步，统一切割 
III. 海量用户下的运营能力 
!   面对持续增长的用户压力，如何处理？扩容 
!   面对突发的请求量和业务暴涨，如何应对？ 防过载 
!   面对日益恶化的互联网环境，如何保持用户体验？ 
多IDC部署 
!   如果深圳地震了，是否能够继续运营？   设备冗余 
持续的扩容能力 
!  业务逻辑要能支持无限扩容 
!  存储无关模块的快速扩容 
!  存储模块的有序扩容 
 
不做无准备扩容 
!  对系统负荷和容量有深刻的认识 
!  系统的短板效应 
!  时刻关注系统状况 
平滑扩容 
!  对用户和其他模块透明 
!  动态和灰度扩容 
过载保护  　雪崩 
!   系统的性能与负载曲线 























	











































	













































 

雪崩的原因 
!   用户的行为无法控制 
1.   反复登录 
2.   疯狂刷新页面 
!   系统的高度耦合性使得模块之间互相依赖 
1.   多米诺骨牌效应 
2.   单点故障效应 
曾经的案例 
!  Dir请求数过多，导致系统雪崩，中断服务8小时。 
!  奥运门票销售第一天，中国银行网点全部崩溃。 
!  CGX事件导致QQ.com服务崩溃。 
防止雪崩 
!  深刻了解系统的瓶颈 
!  限定系统处理能力 
!  20%的崩溃不应该影响80%的用户 
!  优先保证重点用户的服务 
接入现状  问题 
!  电信网通互访困难 
!  长途链路很不稳定 
!  特定路由无法连通 
!  单IDC难以覆盖全球用户 
马甲1 00: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