1.4亿在线背后的故事 —— 腾讯 QQ IM后台架构的演变与启发.ppt

Grandy的故事：grandy修改配置表，要先写好where子句再写前面的语句。 服务可用性从原来的2个9提升到了4个9接近5个9，与google同级。 略讲，强调两套、有容灾指挥中心，且在两个IDC P15，画一下conn进程划分的图 看时间充裕度 详细解释 强调一下复杂性 强调一下是分布到不同的城市 详细解释 做一个万级在线的IM很容易，做一个亿级在线的IM很难 IT成本是互联网企业生死存亡的决定性因素。 互联网行业是新兴行业，服务的架构设计和开发运营没有前车可鉴，腾讯作为互联网行业中不可或缺的企业，在这一块积累了行业内领先的体系化的设计/运营哲学，我们称之为海量服务之道。 从下到上一次是：价值观、意识、方法 P15，画一下conn进程划分的图 自己是腾讯第一个培养出的T4 04年前的，很多是听说或者推测。05年后的，很多是亲身经历。 做一个万级在线的IM很容易，做一个亿级在线的IM很难 这里一定要强调一下：这个级别的架构，是从代码推测出来的，不一定是历史真实。 提问：状态获取的流程有哪些优缺点？ 优点：不限制被加好友的个数 缺点：A的好友表有B，但是反过来没有时：A通知B只有一次机会，丢包就没了；而A获取B不实时。 此页略讲，甚至不讲 此页略讲，别花时间计算。 内存占用只是概算，实际上确实可以通过一些手段减少内存占用，但是不可能有很大的提升 强调与1.0的区别：有了Remote 提问：实时通知的3种方式，各有什么优缺点？ 直接发包：最简单，但是不能应对某些NAT，也不能应对TCP接入 伪装IP发包：编程难度大，可以应对NAT，但是不能应对TCP接入，有时还会被IDC自己的网络设备拦住 通过真正的接入服务器发包：可以应对所有情况，但是成本高 所以实际演变的顺序就是上面的顺序 此页略讲甚至不讲 腾讯：2010年报：196.46E RMB / IM活跃账户数6.476E / 12个月 = 2.53 RMB 中国移动：2010年报：73RMB 绝不使用企业级解决方案：Google牛人的话。 万有一失的无锁设计：通过业务流程的巧妙设计来避免使用锁。举例：设置隐身可见（状态进程）与加好友（好友进程）的冲突没关系；但是LocalOnlineRecord中对好友表位置指针的修改只有登录进程能做。 用户态IPC：使用共享内存设计出用户态的FIFO 绝不使用企业级解决方案：Google牛人的话。 万有一失的无锁设计：通过业务流程的巧妙设计来避免使用锁。举例：设置隐身可见（状态进程）与加好友（好友进程）的冲突没关系；但是LocalOnlineRecord中对好友表位置指针的修改只有登录进程能做。 用户态IPC：使用共享内存设计出用户态的FIFO 略讲，别花时间强调困难 手机从不敢离身：洗澡也得带着手机；从来不敢去游泳 发布新代码提心吊胆：小特性导致CPU100%，大量用户掉线 时不时要扩容，又烦又怕：刚刚接手Conn时，每周扩容两次，感觉自己都不是程序员了。而且又担心配置错误导致事故。 时不时要紧急恢复服务：几乎每人每周都要紧急处理一两次设备故障。 这页只是说一下发现了四方面的问题，不具体解释，后续会一个一个分析和解决 只在一个IDC内是没前途的 本页不展开各种模式的具体含义，只说需要达到什么目标。具体模式的含义后面几页说。 详细解释 CPU100%的故事：一个小特性没写好代码，100% CPU，收到用户投诉才发现异常 CPU100%的故事：一个小特性没写好代码，100% CPU，收到用户投诉才发现异常 这是后台监控系统上截取到的两个示例图，我们对各个维度、各种指标都有监控和告警 这是QQ群消息量的一天曲线，中间有个飙升。从时间上猜猜和什么事情有关系？ 2008年8月18日 刘翔退赛后，群下发消息量 一个图，有最大值、最小值、波动值报警 一个子系统的监控视图，包括了数百个上一页的图片 整个IM后台，有上千个视图 总共，有十万个以上的图片和报警 问题分析及解决（2） 每周有新代码发布，BUG不断出现，严重影响服务 大部分子系统每周发布一个版本的新代码 解决方法 代码review 灰度发布 逛痕郑郭蕴鸦坯闹肇休佩包腔慰床偶凌聋祟逢茶啦轨森乙初构毖探编乎焰1.4亿在线背后的故事 —— 腾讯 QQ IM后台架构的演化与启示1.4亿在线背后的故事 —— 腾讯 QQ IM后台架构的演化与启示 第一周 周末 灰度发布演示 号段7-8 号段7-8 号段5-6 号段5-6 号段3-4 号段3-4 号段1-2 号段1-2 第一周 周一 第一周 周二 第一周 周三 第一周 周四 第一周 原来 周一 周二 周三 周四 沼央迷耀郡顷硷完邵伦耻脖跳浩涎寞脏光竹删庶拇斯夫聘陛凉山眠苍煌俭1.4亿在线背后的故事 —— 腾讯 QQ IM后台架构的演