![1.0 接入服务器的核心数据结构 OnlineIndex OnlineRecord UIN 10003, [FriendUin, Flag] 升序 FList, L1 FList, L2 FList, L3 0 1 10001 10002 10003 10004 POS 0 POS 1 POS 2 POS 3 UIN 10001 LEVEL 1, POS 1 UIN 10004 LEVEL 1, POS 3 UIN 10002 LEVEL 2, POS 2 UIN 10003 LEVEL 3, POS 1 UIN ，标志位，资料 在线状态， IP/Port 好友表位置](https://image.slidesharecdn.com/1-41-111111011226-phpapp02/85/IM1-4-7-320.jpg)
腾讯即时聊天滨惭1.4亿在线背后的故事
- 2. 1.4 亿在线背后的故事 腾讯科技（深圳）有限公司 即通平台部高级技术总监 icezhuang —— QQ IM 后台架构的演化与启示
- 3. 自我介绍 2001- 中国科学技术大学计算机系本科毕业 2004- 中国科学院计算技术研究所硕士毕业 2004- 进入 腾讯 ，参与 IM 后台研发运营 T4 专家 即通平台部 高级技术总监 公司软件开发通道分会 会长 经历了 QQ 在线从千万级到亿级的过程
- 4. 7 亿活跃账户 1.4 亿同时在线 过万台 IM 服务器 百亿级的关系链对数 每天千亿级的服务请求 99.99% 的可用性 团队经历了 QQ 在线从 10 万到 1.4 亿的整个过程，吸取了很多教训 对海量服务的理解是长期积累的结果
- 5. 目录 从十万级到百万级在线 千万级在线 亿级在线 总结
- 6. IM 后台 1.0 适用情况 同时在线数较低（十万级） 业务功能非常简单 接入服务器 存储服务器
- 7. 1.0 接入服务器的核心数据结构 OnlineIndex OnlineRecord UIN 10003, [FriendUin, Flag] 升序 FList, L1 FList, L2 FList, L3 0 1 10001 10002 10003 10004 POS 0 POS 1 POS 2 POS 3 UIN 10001 LEVEL 1, POS 1 UIN 10004 LEVEL 1, POS 3 UIN 10002 LEVEL 2, POS 2 UIN 10003 LEVEL 3, POS 1 UIN ，标志位，资料 在线状态， IP/Port 好友表位置
- 8. IM 后台 1.0 的典型业务流程 登录 实时通知 定期拉取 在线状态的获取 接入服务器 存储服务器
- 9. IM 后台 1.5 需要 更好地支持业务 支持视频、语音、传文件等实时宽带业务 支持更多类型的用户资料 增加 长连接 服务器 为无法直连的客户端进行实时宽带数据中转 对存储服务器进行 轻重分离 核心服务器保证稳定 扩展服务器快速支持业务 长连接服务器 扩展存储服务器 接入服务器 核心存储服务器
- 10. 第一代架构难以支持百万级在线 达到一百万在线时，老架构会有各方面的瓶颈出现 以接入服务器的内存为例，单个在线用户的存储量约为 2KB 索引和在线状态 50 字节 好友表 400 个好友 * 5 字节 / 好友 = 2000 字节 大致来说， 2G 内存只能支持一百万在线用户 进一步地，还有 CPU/ 网卡包量和流量 / 交换机流量等瓶颈 其他服务器也有类似情况 单台服务器支撑不下所有在线用户 / 注册用户 第一代架构无以为继，必须升级！
- 11. IM 后台 2.0 单台服务器扩展成集群 增加状态同步服务器 在接入服务器之间同步在线状态
- 12. 2.0 接入服务器的核心数据结构 0 1 10001 10002 10003 10004 OnlineIndex LocalOnlineRecord RemoteOnlineRecord UIN 在线状态， IP/Port 接入服务器 ID UIN 10001 LEVEL 1, POS 1 UIN 10004 LEVEL 1, POS 3 Local POS 0 Local POS 1 Remote POS 2 Remote POS 3 UIN 10002 @ServerID 3 UIN 10003 @ServerID 5
- 13. IM 后台 2.0 的典型业务流程 2001 年， QQ 同时在线突破一百万 登录 定期拉取 实时通知 在线状态的获取 （三种方式）
- 14. IM 后台 2.5 支持 QQ 群等新业务
- 15. 启示：十万级到百万级在线的关键技术 高性能； 7 乘 24 小时连续服务 Kenny“ 违抗” PonyMa 的故事 ARPU 对比：中国移动 73 ，腾讯 2.5 PCU/Box ：某著名 IM 数万； QQ 数十万 CTO ： IT 成本的高低决定互联网公司的存亡 只用传统 IT 行业 1/10 到 1/100 的 IT 成本 高性能 OICQ 的故事 用户忍耐度对比：信用卡系统维护 VS 用脚投票 7 乘 24 小时连续服务
- 16. QQ 后台如何实现高性能 绝不使用公司级解决方案 逻辑层多进程 万有一失的无锁设计 用户态 IPC MySQL 分库分表 好友表自写文件存储 …… 用户 10003 ，好友表： 10001,0x0 ； 10020,0x0 用户 10003 ，好友表： 10001,0x0 ； 10020,0x1 用户 10003 ，好友表： 10001,0x0 ； 10005,0x1 ； 10020,0x0 接入服务器 接入进程 登录进程 好友进程 状态进程
- 17. QQ 后台如何实现高性能 绝不使用公司级解决方案 逻辑层多进程 万有一失的无锁设计 用户态 IPC MySQL 分库分表 好友表自写文件存储 …… UIN 10001 UIN 10001 FList, L2 FList, L3 UIN 10001 LEVEL 1, POS 1 UIN 10004 LEVEL 1, POS 3 OnlineRecord UIN 10004 UIN 1000 ？
- 18. QQ 后台如何实现 7 乘 24 小时连续服务 大系统小做 平滑重构 在高速行驶的列车上更换发动机 核心数据放入共享内存 接入层与逻辑层分离 命令分发动态配置化
- 19. 目录 从十万级到百万级在线 千万级在线 亿级在线 总结
- 20. 第二代架构难以支持千万级在线 同步流量太大，状态同步服务器遇到单机瓶颈 所有在线用户的在线状态信息量太大，单台接入服务器存不下 如果在线数进一步增加，则甚至单台状态同步服务器也存不下 单台状态同步服务器支撑不下所有在线用户 单台接入服务器支撑不下所有在线用户的在线状态信息 第二代架构无以为继，必须再次升级！
- 21. IM 后台 3.0 状态同步服务器改造成同步集群 其他集群也做相应的改造 2005 年， QQ 同时在线突破一千万
- 22. 根本来不及高兴：我们再也受不了了！ 手机从不敢离身 发布新代码提心吊胆 时不时要扩容，又烦又怕 时不时要紧急恢复服务 时不时被用户骂、被老板 K 到底怎么了？
- 23. 深入分析，我们发现了什么 后台机器越来越多，单机死机 / 故障经常出现， IDC 故障也不少，影响服务，也影响人员生活 每周有新代码发布， BUG 不断出现，严重影响服务 监控机制原始、报警设置不全，出事了都不知道 运维操作通过 vim 或者 mysql 进行，非常容易失误
- 24. 问题分析和解决（ 1 ） 后台机器越来越多，单机死机 / 故障经常出现， IDC 故障也不少，影响服务，也影响人员生活 传统行业设备少单价高，故障很少出现 互联网行业设备多单价低，故障是常态
- 25. IM 后台 3.0 的容错 / 容灾分析 每个集群只有一份 机器选择全人工配置 集中在一个 IDC
- 26. IDC 的实际可用性只有 2 个 9 老架构没前途，必须进行容灾改造！ 租来的 IDC 的级别： B 或 C
- 27. 容灾改造的思路 存储集群：半自动切换模式 主 / 从服务器 从服务器死机，业务不受影响 主服务器死机，多数命令不受影响，修改资料命令受影响 业务集群、接入集群、同步集群：自动切换模式 迅速应对死机等情况，基本不影响业务 分布在两套 IDC 可以应对 IDC 整体故障
- 28. 业务集群的容灾改造 业务命令流 设备状态流 接入集群 业务集群 @ IDC1 业务集群 @ IDC2 指挥中心 @ IDC1 指挥中心 @ IDC2
- 29. 问题分析和解决（ 2 ） 每周有新代码发布， BUG 不断出现，严重影响服务 大部分子系统每周发布一个版本的新代码 解决方法 代码 review 灰度发布
- 30. 灰度发布演示 第一周 周末 号段 7-8 号段 7-8 号段 5-6 号段 5-6 号段 3-4 号段 3-4 号段 1-2 号段 1-2 第一周 周一 第一周 周二 第一周 周三 第一周 周四 第一周 原来 周一 周二 周三 周四
- 31. 问题分析和解决（ 3 ） 监控机制原始、报警设置不全，出事了都不知道 CPU 100% 的故事 解决方法 完善监控和报警
- 32. 完善监控和报警
- 33. 完善监控和报警
- 34. 完善监控和报警
- 35. 完善监控和报警
- 36. 完善监控和报警
- 37. 问题分析和解决（ 4 ） 运维操作通过 vim 或者 mysql 进行，非常容易失误 Grandy 的故事 解决方法 运维操作 Web 化（半自动化）、自动化 IM 后台 3.5 的运维页面已经废除，后面有 IM 后台 4.0 的运维页面截图
- 39. IM 后台 3.5 架构 长连接集群 同步集群 接入集群 存储集群 若干个业务集群 长连接集群 同步集群 接入集群 存储集群 若干个业务集群 容灾指挥集群 IDC1 IDC2 运维控制集群 监控报警集群 容灾指挥集群 运维控制集群 监控报警集群 运维控制集群 监控报警集群 监控报警集群 运维控制集群 监控报警集群 运维控制集群 监控报警集群 运维控制集群 监控报警集群 容灾指挥集群 运维控制集群 监控报警集群 运维控制集群 监控报警集群 容灾指挥集群 容灾指挥集群 运维控制集群 监控报警集群 运维控制集群 监控报警集群
- 40. 启示：千万级在线的关键技术 对外提供高可用性的服务 对内提供高可运维性的系统 灰度发布 运营监控 容灾 运维自动化 / 半自动化 高可用性；高可运维性
Editor's Notes
- #3: P15 ，画一下 conn 进程划分的图
- #4: 自己是腾讯第一个培养出的 T4 04 年前的，很多是听说或者推测。 05 年后的，很多是亲身经历。
- #5: 做一个万级在线的 IM 很容易，做一个亿级在线的 IM 很难
- #6: 这里一定要强调一下：这个级别的架构，是从代码推测出来的，不一定是历史真实。
- #9: 提问：状态获取的流程有哪些优缺点？ 优点：不限制被加好友的个数 缺点： A 的好友表有 B ，但是反过来没有时： A 通知 B 只有一次机会，丢包就没了；而 A 获取 B 不实时。
- #10: 此页略讲，甚至不讲
- #11: 此页略讲，别花时间计算。 内存占用只是概算，实际上确实可以通过一些手段减少内存占用，但是不可能有很大的提升
- #13: 强调与 1.0 的区别：有了 Remote
- #14: 提问：实时通知的 3 种方式，各有什么优缺点？ 直接发包：最简单，但是不能应对某些 NAT ，也不能应对 TCP 接入 伪装 IP 发包：编程难度大，可以应对 NAT ，但是不能应对 TCP 接入，有时还会被 IDC 自己的网络设备拦住 通过真正的接入服务器发包：可以应对所有情况，但是成本高 所以实际演变的顺序就是上面的顺序
- #15: 此页略讲甚至不讲
- #16: 腾讯： 2010 年报： 196.46E RMB / IM 活跃账户数 6.476E / 12 个月 = 2.53 RMB 中国移动： 2010 年报： 73RMB
- #17: 绝不使用公司级解决方案： Google 牛人的话。 万有一失的无锁设计：通过业务流程的巧妙设计来避免使用锁。举例：设置隐身可见（状态进程）与加好友（好友进程）的冲突没关系；但是 LocalOnlineRecord 中对好友表位置指针的修改只有登录进程能做。 用户态 IPC ：使用共享内存设计出用户态的 FIFO
- #18: 绝不使用公司级解决方案： Google 牛人的话。 万有一失的无锁设计：通过业务流程的巧妙设计来避免使用锁。举例：设置隐身可见（状态进程）与加好友（好友进程）的冲突没关系；但是 LocalOnlineRecord 中对好友表位置指针的修改只有登录进程能做。 用户态 IPC ：使用共享内存设计出用户态的 FIFO
- #21: 略讲，别花时间强调困难
- #23: 手机从不敢离身：洗澡也得带着手机；从来不敢去游泳 发布新代码提心吊胆：小特性导致 CPU100% ，大量用户掉线 时不时要扩容，又烦又怕：刚刚接手 Conn 时，每周扩容两次，感觉自己都不是程序员了。而且又担心配置错误导致事故。 时不时要紧急恢复服务：几乎每人每周都要紧急处理一两次设备故障。
- #24: 这页只是说一下发现了四方面的问题，不具体解释，后续会一个一个分析和解决
- #27: 只在一个 IDC 内是没前途的
- #28: 本页不展开各种模式的具体含义，只说需要达到什么目标。具体模式的含义后面几页说。
- #29: 详细解释
- #30: CPU100% 的故事：一个小特性没写好代码， 100% CPU ，收到用户投诉才发现异常
- #32: CPU100% 的故事：一个小特性没写好代码， 100% CPU ，收到用户投诉才发现异常
- #33: 这是后台监控系统上截取到的两个示例图，我们对各个维度、各种指标都有监控和告警
- #34: 这是 QQ 群消息量的一天曲线，中间有个飙升。从时间上猜猜和什么事情有关系？ 2008 年 8 月 18 日 刘翔退赛后，群下发消息量
- #35: 一个图，有最大值、最小值、波动值报警
- #36: 一个子系统的监控视图，包括了数百个上一页的图片
- #37: 整个 IM 后台，有上千个视图 总共，有十万个以上的图片和报警
- #38: Grandy 的故事： grandy 修改配置表，要先写好 where 子句再写前面的语句。
- #39: 服务可用性从原来的 2 个 9 提升到了 4 个 9 接近 5 个 9 ，与 google 同级。
- #40: 略讲，强调两套、有容灾指挥中心，且在两个 IDC