1 4亿在线背后的故事1.pptVIP

只在一个IDC内是没前途的 本页不展开各种模式的具体含义，只说需要达到什么目标。具体模式的含义后面几页说。 详细解释 CPU100%的故事：一个小特性没写好代码，100% CPU，收到用户投诉才发现异常 CPU100%的故事：一个小特性没写好代码，100% CPU，收到用户投诉才发现异常 这是后台监控系统上截取到的两个示例图，我们对各个维度、各种指标都有监控和告警 这是QQ群消息量的一天曲线，中间有个飙升。从时间上猜猜和什么事情有关系？ 2008年8月18日 刘翔退赛后，群下发消息量 一个图，有最大值、最小值、波动值报警 一个子系统的监控视图，包括了数百个上一页的图片 整个IM后台，有上千个视图 总共，有十万个以上的图片和报警 Grandy的故事：grandy修改配置表，要先写好where子句再写前面的语句。 服务可用性从原来的2个9提升到了4个9接近5个9，与google同级。 略讲，强调两套、有容灾指挥中心，且在两个IDC 问题分析和解决（3） 监控机制原始、报警设置不全，出事了都不知道 CPU 100%的故事 解决方法 完善监控和报警 完善监控和报警 完善监控和报警 完善监控和报警 完善监控和报警 完善监控和报警 问题分析和解决（4） 运维操作通过vim或者mysql进行，非常容易失误 Grandy的故事 解决方法 运维操作Web化（半自动化）、自动化 IM后台3.5的运维页面已经废除，后面有IM后台4.0的运维页面截图 服务可用性终于提升到了行业先进水平 IM后台3.5架构 长连接集群 同步集群 接入集群 存储集群 若干个业务集群 长连接集群 同步集群 接入集群 存储集群 若干个业务集群 容灾指挥集群 IDC1 IDC2 运维控制集群 监控报警集群 容灾指挥集群 运维控制集群 监控报警集群 运维控制集群 监控报警集群 监控报警集群 运维控制集群 监控报警集群 运维控制集群 监控报警集群 运维控制集群 监控报警集群 容灾指挥集群 运维控制集群 监控报警集群 运维控制集群 监控报警集群 容灾指挥集群 容灾指挥集群 运维控制集群 监控报警集群 运维控制集群 监控报警集群 启示：千万级在线的关键技术 对外提供高可用性的服务 对内提供高可运维性的系统 灰度发布 运营监控 容灾 运维自动化/半自动化 高可用性；高可运维性 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时，每周扩容两次，感觉自己都不是程序员了。而且又担心配置错误导致事故。 时不时要紧急恢复服务：几乎每人每周都要紧急处理一两次设备故障。 这页只是说一下发现了四方面的问题，不具体解释，后续会一个