亿在线背后的故事1ppt课件

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