Downloaded 13 times
![UIN 10003, [FriendUin, Flag] 升序
FList, L1 FList, L2
FList, L3
1.0 接入服 器的核心数据务 结构
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
好友表位置
OnlineIndex OnlineRecord](https://image.slidesharecdn.com/1-4-111227001108-phpapp01/85/1-4-7-320.jpg)
1.4亿在线背后的故事
- 1. 大 堂走 北航腾讯讲 进 2011.10.31 Djt.open.qq.com
- 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. UIN 10003, [FriendUin,Flag] 升序 FList, L1 FList, L2 FList, L3 1.0 接入服 器的核心数据务 结构 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 好友表位置 OnlineIndex OnlineRecord
- 8. IM 后台 1.0的典型 流程业务 登录 通知实时 定期拉取 在 状 的 取线 态 获 接入服 器务接入服 器务 存 服 器储 务存 服 器储 务
- 9. IM 后台 1.5 需要更好地支持业务 支持 、 音、 文件等视频 语 传 实 时宽带业务 支持更多类型的用 料户资 增加 接长连 服 器务 无法直 的客 端 行为 连 户 进 实时 数据中宽带 转 存 服 器 行对 储 务 进 重分离轻 核心服 器保 定务 证稳 展服 器快速支持扩 务 业务 接服 器长连 务接服 器长连 务 展存 服 器扩 储 务展存 服 器扩 储 务 接入服 器务接入服 器务 核心存 服 器储 务核心存 服 器储 务
- 10. 第一代架 以支持百万 在构难级 线 到一百万在 ，老架 会有各方面的瓶 出达 线时 构 颈 现 以接入服 器的内存 例， 个在 用 的存 量务 为 单 线 户 储 约为 2KB 索引和在 状线 态 50 字节 好友表 400 个好友 * 5 字节 / 好友 = 2000 字节 大致来 ，说 2G 内存只能支持一百万在 用线 户 一步地， 有进 还 CPU/ 网卡包量和流量 / 交 机流量等瓶换 颈 其他服 器也有类似情况务 台服 器支 不下所有在 用单 务 撑 线 户 / 注册用户 第一代架 无以 ，必 升 ！构 为继 须 级
- 11. IM 后台 2.0 台服 器 展成集群单 务 扩 增加状 同步服 器态 务 在接入服 器之 同步在 状务 间 线 态
- 12. UIN 10001 LEVEL 1,POS 1 UIN 10004 LEVEL 1, POS 3 2.0 接入服 器的核心数据务 结构 0 1 10001 10002 10003 10004 Local POS 0 Local POS 1 Remote POS 2 Remote POS 3 OnlineIndex LocalOnlineRecord UIN 10002 @ServerID 3 UIN 10003 @ServerID 5 RemoteOnlineRecord UIN 在线状态， IP/Port 接入服务器 ID
- 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 10004UIN 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集群业务@ IDC1 集群业务 @ IDC2集群业务 @ IDC2 指 中心挥 @ IDC1指 中心挥 @ IDC1 指 中心挥 @ IDC2指 中心挥 @ 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 的 面截运维页 图
- 38. 服 可用性 于提升到了行先 水平务 终 业 进
- 39. IM 后台 3.5架构 接集群长连接集群长连 同步集群同步集群 接入集群接入集群 存 集群储存 集群储若干个 集群业务若干个 集群业务 接集群长连接集群长连 同步集群同步集群 接入集群接入集群 存 集群储存 集群储 若干个 集群业务若干个 集群业务 容灾指 集群挥容灾指 集群挥 IDC1 IDC2 控制集群运维控制集群运维 控 警集群监 报控 警集群监 报 容灾指 集群挥容灾指 集群挥控制集群运维控制集群运维 控 警集群监 报控 警集群监 报 控制集群运维控制集群运维 控 警集群监 报控 警集群监 报 控 警集群监 报控 警集群监 报 控制集群运维控制集群运维 控 警集群监 报控 警集群监 报 控制集群运维控制集群运维 控 警集群监 报控 警集群监 报 控制集群运维控制集群运维 控 警集群监 报控 警集群监 报 容灾指 集群挥容灾指 集群挥 控制集群运维控制集群运维 控 警集群监 报控 警集群监 报 控制集群运维控制集群运维 控 警集群监 报控 警集群监 报 容灾指 集群挥容灾指 集群挥 容灾指 集群挥容灾指 集群挥 控制集群运维控制集群运维 控 警集群监 报控 警集群监 报 控制集群运维控制集群运维 控 警集群监 报控 警集群监 报
- 40. 示：千万 在 的技启 级 线 关键 术 外提供高可用性的服对 务 内提供高可 性的系对 运维 统 灰度 布发 控运营监 容灾 自 化运维 动 / 半自 化动 高可用性；高可 性运维
- 41. 大 堂走 北航腾讯讲 进 2011.10.31 Djt.open.qq.com
- 42. 1.4 在 背后的故事亿线 (2) 科技（深圳）有限公司腾讯 即通平台部高 技级 术总监 icezhuang ——QQ IM 后台架 的演化与 示构 启
- 43. 目录 从十万 到百万在级 级 线 千万 在级 线 在亿级 线 总结
- 44. 随着 代的接近，新 又来了亿时烦恼 活性：灵 “ 昵称” 度增加一半，需要 个月长 两 增加“故 ”字段，需要 个月乡 两 最大好友数从 500 成变 1000 ，需要三个月 代的重要能力：亿时 上万好友 私权限控制隐 PC QQ 与手机 QQ 互别 踢 微信与 QQ 互通 地容灾异 IM 后台从 1.0 到 3.5 都是在原来基 上做改造升 ，但是：础 级 持 打 丁已 以支 在续 补 经难 撑亿级 线 IM 后台 4.0 必 从 始，重新须 头开 设计实现 ！ 太差！ 想都 想！别
- 45. IM 后台 4.0存 系 架储 统 构
- 46. IM 后台 4.0存 系 面储 统 运维页
- 47. IM 后台 4.0存 系 成果储 统 历时 3 年完成 千万 好友级 私权限控制隐 活 展字段灵 扩 高可 性运维 操作 件化运维 组 自 移负载 动转 高性能 自写存储层
- 48. IM 后台 4.0通信系 架统 逻辑 构
- 49. IM 后台 4.0通信系 物理架统 构
- 50. IM 后台 4.0通信系 面统 运维页
- 51. IM 后台 4.0通信系 段成果统 阶 历时 2+ 年完成 多点登录 支持 5 至 10 个 例同 在亿 实 时 线 方便接入微信等多种业务 区域自治 高可 性运维 物理架 到机架构详细 故障分析智能化
- 52. 示： 在 的技启 亿级 线 关键 术 提供高 活性的 支持灵 业务 传统 IT 行 可以半年到 年出一个新版本业 两 互 网行 要求每个月出一个新版本联 业 同 保持高性能、高可用性、高可 性时 运维 高性能；高可用性；高可 性；高 活性运维 灵
- 53. 腾讯 IM 服的未来之路务 全球化分布 高效率的研发 控告警的智能化监
- 54. 目录 从十万 到百万在级 级 线 千万 在级 线 在亿级 线 总结
- 55. QQ IM 后台技演化的 示术 启 1.0 十万 、级 2.0 百万级 高性能； 7 乘 24 小 服时连续 务 3.0 千万级 高可用性；高可 性运维 4.0 亿级 高性能；高可用性；高可 性；高 活性运维 灵
- 56. QQ IM 后台技演化的 示术 启 只 功能，不实现 难 高性能 / 低成本 高可用性 高可 性运维 高 活性灵 很 ！难 在 量每提升一个量 ，技 度也提升一个量线 级 术难 级
- 57. 7 活亿 跃账户1.4 同 在亿 时 线 万台过 IM 服 器务 百 的 系 数亿级 关 链对 每天千 的服 求亿级 务请 99.99% 的可用性 了团队经历 QQ 在 从线 10 万到 1.4 的整个 程，吸取了很多教亿 过 训 海量服 的理解是 期 累的 果对 务 长 积 结
- 58. 互 网与联 传统IT 行 区 很大业 别 互 网行 有自己的技 律，需要做自己的技 累联 业 术规 术积 传统 IT 行业 互 网行联 业 ARPU 数十元 低于三元 IT 成本的重要性 只占 成本的不到总 10% 占 成本的大部分总 数量与 价设备 单 数量少 价高单 数量多 价低单 故障设备 少极 常态 延 的忍耐度对 迟 高较 很低 数据 的忍耐度对 错误 万无一失 万有一失 版本更新速度 半年以上 一个月左右
- 59. 在海量服 方面的技 累和：腾讯 务 术积 总结 《海量服 之道》系列 程务 课 Set 模型 全网 度调 灰度升级 保过载 护 立体 控监 自 部署动 柔性可用 大系 做小统 先扛住再 化优 重 生活边 构边 干干净净 有 服损 务 动态运营
- 60.
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
- #43 P15，画一下conn进程划分的图
- #46 看时间充裕度
- #48 详细解释
- #49 强调一下复杂性
- #50 强调一下是分布到不同的城市
- #52 详细解释
- #58 做一个万级在线的IM很容易，做一个亿级在线的IM很难
- #59 IT成本是互联网企业生死存亡的决定性因素。
- #60 互联网行业是新兴行业，服务的架构设计和开发运营没有前车可鉴，腾讯作为互联网行业中不可或缺的企业，在这一块积累了行业内领先的体系化的设计/运营哲学，我们称之为海量服务之道。 从下到上一次是：价值观、意识、方法