腾讯大讲堂44 QQGame后台开发介绍.pptVIP

IV. 在现实中挣扎 一个复杂的系统，如何应对各种故障？ 一个庞大的需求，如何进行开发？ 进度排不过来，产品和策划该怎么办？ 新业务上线，频繁出现问题。 大规模设备升级＝＝无休止的加班。 系统解耦合 —— 抗风险 一个大灯泡和十个小灯泡的亮度是一样的，抗风险能力却不同 QQGame可以分拆成多个系统模块 单一模块的故障不影响整个系统的服务 非０即１不是我们的选择。 大需求化小 —— 多次迭代 化整为零：需求是可以分解为多个小特性的。 多次迭代：每次专注于一个小特性的开发。 频繁构建： 自动化测试保证代码质量。 分期上线 ——　解决资源冲突 当产品需求和开发资源冲突时怎么办？ 当时间无法保证系统完整上线时怎么办？ 买房可以分期付款，需求也可以分批交付。 还是不要非０即１的选择。 开发和运维人员的现状 大部分的加班都是由于版本回退造成的 新业务的发布没有不出问题 切割时提心吊胆，内分泌失调 灰度升级 ——０和１之外的选择 开发不是圣人，测试不是神仙，新版本出问题是必然的，不出问题是偶然的。 小概率问题能在海量用户前暴露 新业务一定要灰度升级 一定要做到真正的灰度 客户端的灰度发布：控制放量 Svr的灰度发布：随机、按号段、按大区。 Svr和客户端同时灰度发布： Svr要能做到新老版本的兼容 客户端也要做到新老版本的兼容 隔离新老版本的访问，新版本svr出现的问题只影响新版本的客户端 Q A * 中心配置策略 大容量接入服务器 游戏服务器面临的问题： 大数据量快速交互 海量并发数下的响应 解决之道： 接入与逻辑分离的进程模型 采用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个游戏房间 每个游戏都能部署在任意房间里 房间数能够根据游戏运营情况动态调整 数据交换机TCPProxySvr 逻辑层和存储层之间的数据交换机和路由器 使得逻辑层和存储层在部署层面上解耦合 沙漏型结构，便于管理 多种路由方式选择：点对点、Key转发、组播和广播 Proxy本身无状态无存储，便于扩展 TCPProxySvr的路由表 路由表 K1 K2 KN C1 C1 CN Key DB1 DB2 DBN Data Analysis 海量存储GameDBSvr 同时在线：400万 活跃用户数：2000万 注册用户数：3亿2千万 大量的并发游戏币、欢乐豆、游戏积分和游戏数据的更改及查询 GameDBSvr进程模型 GameDBSvr的性能 大容量Cache：99%的命中率，直接减少读IO。 多线程处理：逻辑处理和数据库IO分开，提高吞吐率。 数据库调优：Innodb引擎，禁止自动提交事务。 分布的数据中心 64台GameDBSvr，本地存储数据 按号段存储 group key = （UIN16）%256 通过TCPProxySvr全连接所有的MainSvr 存储层的树状扩展模型 DB0 DB0 DB1 DB0 DB2 DB1 DB3 。。。。。。。。。 DB的分裂方式 继承和数据迁移 主从数据同步，统一切割 III. 海量用户下的运营能力 面对持续增长的用户压力，如何处理？——扩容 面对突发的请求量和业务暴涨，如何应对？—— 防过载 面对日益恶化的互联网环境，如何保持用户体验？—— 多IDC部署 如果深圳地震了，是否能够继续运营？ —— 设备冗余 持续的扩容能力 业务逻辑要能支持无限扩容 存储无关模块的快速扩容 存储模块的有序扩容 不做无准备扩容 对系统负荷和容量有深刻的认识 系统的短板效应 时刻关注系统状况 平滑扩容 对用户和其他模块透明 动态和灰度扩容 过载保护 ——　雪崩 系统的性能与负载曲线 雪崩的原因 用户的行为无法控制 反复登录 疯狂刷新页面 系统的高度耦合性使得模块之间互相依赖 多米诺骨牌效应 单点故障效应 曾经的案例 Dir请求数过多，导致系统雪崩，中断服务8小时。 奥运门票销售第一天，中国银行网点全部崩溃。 CGX事件导致QQ.com服务崩溃。 防止雪崩 深刻了解系统的瓶颈 限定系统处理能力 20%的崩溃不应该影响80%的用户 优先保证重点用户的服务 接入现状 —— 问题 电信网通互访困难 长途链路很不稳定 特定路由无法连通