1.4亿在线背后的故事_——_腾讯_QQ_IM后台架构的演化与启示.pptVIP

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 灰度发布 第一周 周末 灰度发布演示 号段7-8 号段7-8 号段5-6 号段5-6 号段3-4 号段3-4 号段1-2 号段1-2 第一周 周一 第一周 周二 第一周 周三 第一周 周四 第一周 原来 周一 周二 周三 周四 问题分析和解决（3） 监控机制原始、报警设置不全，出事了都不知道 CPU 100%的故事 解决方法 完善监控和报警 完善监控和报警 完善监控和报警 完善监控和报警 完善监控和报警 完善监控和报警 问题分析和解决（4） 运维操作通过vim或者mysql进行，非常容易失误 Grandy的故事 解决方法