[企业创新管理--腾讯海量服务之道.ppt

提问：状态获取的流程有哪些优缺点？ 优点：不限制被加好友的个数 缺点：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后台，有上千个视图 总共，有十万个以上的图片和报警 Grandy的故事：grandy修改配置表，要先写好where子句再写前面的语句。 服务可用性从原来的2个9提升到了4个9接近5个9，与google同级。 完善监控和报警 Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile 5.2.0.0. Copyright 2004-2011 Aspose Pty Ltd. Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile 5.2.0.0. Copyright 2004-2011 Aspose Pty Ltd. 完善监控和报警 Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile 5.2.0.0. Copyright 2004-2011 Aspose Pty Ltd. Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile 5.2.0.0. Copyright 2004-2011 Aspose Pty Ltd. 完善监控和报警 Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile 5.2.0.0. Copyright 2004-2011 Aspose Pty Ltd. Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile 5.2.0.0. Copyright 2004-2011 Aspos