《亿在线背后的故事1.ppt》由会员分享，可在线阅读，更多相关《亿在线背后的故事1.ppt（40页珍藏版）》请在三一办公上搜索。
1、腾讯大讲堂走进北航,2011.10.31D,1.4亿在线背后的故事,腾讯科技（深圳）有限公司即通平台部高级技术总监 icezhuang,QQ IM后台架构的演化与启示,自我介绍,2001-中国科学技术大学计算机系本科毕业,2004-中国科学院计算技术研究所硕士毕业,2004-进入腾讯，参与IM后台研发运营,T4专家 即通平台部 高级技术总监 公司软件开发通道分会 会长 经历了QQ在线从千万级到亿级的过程,7亿活跃账户,1.4亿同时在线,过万台IM服务器,百亿级的关系链对数,每天千亿级的服务请求,99.99%的可用性,团队经历了QQ在线从10万到1.4亿的整个过程，吸取了很多教训,对海量服务的理
2、解是长期积累的结果,目录,从十万级到百万级在线 千万级在线 亿级在线 总结,IM后台1.0,适用情况,同时在线数较低（十万级）业务功能非常简单,1.0接入服务器的核心数据结构,OnlineIndex,OnlineRecord,IM后台1.0的典型业务流程,登录,实时通知定期拉取,在线状态的获取,IM后台1.5,需要更好地支持业务支持视频、语音、传文件等实时宽带业务支持更多类型的用户资料增加长连接服务器为无法直连的客户端进行实时宽带数据中转对存储服务器进行轻重分离核心服务器保证稳定扩展服务器快速支持业务,第一代架构难以支持百万级在线,达到一百万在线时，老架构会有各方面的瓶颈出现以接入服务器的内存
3、为例，单个在线用户的存储量约为2KB索引和在线状态 50字节好友表 400个好友*5字节/好友=2000字节大致来说，2G内存只能支持一百万在线用户进一步地，还有CPU/网卡包量和流量/交换机流量等瓶颈其他服务器也有类似情况单台服务器支撑不下所有在线用户/注册用户,第一代架构无以为继，必须升级！,IM后台2.0,单台服务器扩展成集群增加状态同步服务器在接入服务器之间同步在线状态,2.0接入服务器的核心数据结构,0,1,10001,10002,10003,10004,OnlineIndex,LocalOnlineRecord,RemoteOnlineRecord,UIN在线状态，IP/Port接
4、入服务器ID,IM后台2.0的典型业务流程,2001年，QQ同时在线突破一百万,登录,定期拉取实时通知,在线状态的获取,（三种方式）,IM后台2.5,支持QQ群等新业务,启示：十万级到百万级在线的关键技术,高性能；7乘24小时连续服务,Kenny“违抗”PonyMa的故事ARPU对比：中国移动73，腾讯2.5PCU/Box：某著名IM数万；QQ 数十万CTO：IT成本的高低决定互联网企业的存亡只用传统IT行业1/10到1/100的IT成本 高性能OICQ的故事用户忍耐度对比：信用卡系统维护VS用脚投票 7乘24小时连续服务,QQ后台如何实现高性能,绝不使用企业级解决方案逻辑层多进程万有一失的无
5、锁设计用户态IPCMySQL分库分表好友表自写文件存储,用户10003，好友表：10001,0 x0；10020,0 x0,用户10003，好友表：10001,0 x0；10020,0 x1,用户10003，好友表：10001,0 x0；10005,0 x1；10020,0 x0,QQ后台如何实现高性能,绝不使用企业级解决方案逻辑层多进程万有一失的无锁设计用户态IPCMySQL分库分表好友表自写文件存储,UIN 10001,UIN 10001,FList,L2,FList,L3,UIN 10001LEVEL 1,POS 1,UIN 10004LEVEL 1,POS 3,OnlineRecord
6、,UIN 10004,UIN 1000？,QQ后台如何实现7乘24小时连续服务,大系统小做平滑重构在高速行驶的列车上更换发动机核心数据放入共享内存接入层与逻辑层分离命令分发动态配置化,目录,从十万级到百万级在线 千万级在线 亿级在线 总结,第二代架构难以支持千万级在线,同步流量太大，状态同步服务器遇到单机瓶颈所有在线用户的在线状态信息量太大，单台接入服务器存不下如果在线数进一步增加，则甚至单台状态同步服务器也存不下单台状态同步服务器支撑不下所有在线用户单台接入服务器支撑不下所有在线用户的在线状态信息,第二代架构无以为继，必须再次升级！,IM后台3.0,状态同步服务器改造成同步集群其他集群也做相
7、应的改造,2005年，QQ同时在线突破一千万,根本来不及高兴：我们再也受不了了！,手机从不敢离身发布新代码提心吊胆时不时要扩容，又烦又怕时不时要紧急恢复服务时不时被用户骂、被老板K到底怎么了？,深入分析，我们发现了什么,后台机器越来越多，单机死机/故障经常出现，IDC故障也不少，影响服务，也影响人员生活每周有新代码发布，BUG不断出现，严重影响服务监控机制原始、报警设置不全，出事了都不知道运维操作通过vim或者mysql进行，非常容易失误,问题分析和解决（1）,后台机器越来越多，单机死机/故障经常出现，IDC故障也不少，影响服务，也影响人员生活传统行业设备少单价高，故障很少出现互联网行业设备多
8、单价低，故障是常态,IM后台3.0的容错/容灾分析,每个集群只有一份机器选择全人工配置集中在一个IDC,IDC的实际可用性只有2个9,老架构没前途，必须进行容灾改造！,租来的IDC的级别：B或C,容灾改造的思路,存储集群：半自动切换模式主/从服务器从服务器死机，业务不受影响主服务器死机，多数命令不受影响，修改资料命令受影响 业务集群、接入集群、同步集群：自动切换模式迅速应对死机等情况，基本不影响业务 分布在两套IDC可以应对IDC整体故障,业务集群的容灾改造,业务命令流,设备状态流,接入集群,业务集群 IDC1,业务集群 IDC2,指挥中心 IDC1,指挥中心 IDC2,问题分析和解决（2）,
9、每周有新代码发布，BUG不断出现，严重影响服务大部分子系统每周发布一个版本的新代码解决方法代码review灰度发布,第一周 周末,灰度发布演示,号段7-8,号段7-8,号段5-6,号段5-6,号段3-4,号段3-4,号段1-2,号段1-2,第一周 周一,第一周 周二,第一周 周三,第一周 周四,第一周 原来,周一,周二,周三,周四,问题分析和解决（3）,监控机制原始、报警设置不全，出事了都不知道CPU 100%的故事解决方法完善监控和报警,完善监控和报警,完善监控和报警,完善监控和报警,完善监控和报警,完善监控和报警,问题分析和解决（4）,运维操作通过vim或者mysql进行，非常容易失误Grandy的故事解决方法运维操作Web化（半自动化）、自动化IM后台3.5的运维页面已经废除，后面有IM后台4.0的运维页面截图,服务可用性终于提升到了行业先进水平,IM后台3.5架构,启示：千万级在线的关键技术,对外提供高可用性的服务对内提供高可运维性的系统灰度发布运营监控容灾运维自动化/半自动化,高可用性；高可运维性,
