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. Q & A