451.4亿在线背后的故事(1)

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