More Related Content
Similar to 1.4亿在线背后的故事 (20)
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 的整个 程,吸取了很多教亿 过 训
海量服 的理解是 期 累的 果对 务 长 积 结
- 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 同 在 突破一百万时 线
登录
定期拉取
通知实时
在 状 的 取线 态 获
(三 方式)种
- 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 小时连续
服务
大系 小做统
平滑重构
在高速行 的列 上更 机驶 车 换发动
核心数据放入共享内存
接入 与 分离层 逻辑层
命令分 配置化发动态
- 20. 第二代架 以支持千万 在构难 级 线
同步流量太大,状 同步服 器遇到 机瓶态 务 单 颈
所有在 用 的在 状 信息量太大, 台接入服线 户 线 态 单 务
器存不下
如果在 数 一步增加, 甚至 台状 同步服 器也存线 进 则 单 态 务
不下
台状 同步服 器支 不下所有在 用单 态 务 撑 线 户
台接入服 器支 不下所有在 用 的在 状 信单 务 撑 线 户 线 态
息
第二代架 无以 ,必 再次升 !构 为继 须 级
- 21. IM 后台 3.0
状 同步服 器改造成同步集群态 务
其他集群也做相 的改造应
2005 年, QQ 同 在 突破一千万时 线
- 22. 根本来不及高 :我 再也受不了了!兴 们
手机从不敢离身
布新代 提心吊胆发 码
不 要 容,又 又怕时 时 扩 烦
不 要 急恢 服时 时 紧 复 务
不 被用 、被老板时 时 户骂 K
到底怎么了?
- 23. 深入分析,我 了什么们发现
后台机器越来越多, 机死机单 / 故障 常出 ,经 现 IDC 故
障也不少,影响服 ,也影响人 生活务 员
每周有新代 布,码发 BUG 不断出 , 重影响服现 严 务
控机制原始、 警 置不全,出事了都不知道监 报 设
操作通运维 过 vim 或者 mysql 行,非常容易失进 误
- 24. 分析和解决(问题 1 )
后台机器越来越多, 机死机单 / 故障 常出 ,经 现 IDC
故障也不少,影响服 ,也影响人 生活务 员
行 少 价高,故障很少出传统 业设备 单 现
互 网行 多 价低,故障是常联 业设备 单 态
- 25. IM 后台 3.0 的容错 / 容灾分析
每个集群只有一份
机器 全人工配置选择
集中在一个 IDC
- 27. 容灾改造的思路
存 集群:半自 切 模式储 动 换
主 / 从服 器务
从服 器死机, 不受影响务 业务
主服 器死机,多数命令不受影响,修改 料命令受影响务 资
集群、接入集群、同步集群:自 切 模式业务 动 换
迅速 死机等情况,基本不影响应对 业务
分布在 套两 IDC
可以应对 IDC 整体故障
- 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% 的故事
解决方法
完善 控和 警监 报
- 37. 分析和解决(问题 4 )
操作通运维 过 vim 或者 mysql 行,非常容易失进 误
Grandy 的故事
解决方法
操作运维 Web 化(半自 化)、自 化动 动
• IM 后台 3.5 的 面已 除,后面有运维页 经废 IM 后台 4.0 的 面截运维页 图
- 39. IM 后台 3.5 架构
接集群长连接集群长连
同步集群同步集群
接入集群接入集群
存 集群储存 集群储若干个 集群业务若干个 集群业务
接集群长连接集群长连
同步集群同步集群
接入集群接入集群
存 集群储存 集群储 若干个 集群业务若干个 集群业务
容灾指 集群挥容灾指 集群挥
IDC1 IDC2
控制集群运维控制集群运维
控 警集群监 报控 警集群监 报
容灾指 集群挥容灾指 集群挥控制集群运维控制集群运维
控 警集群监 报控 警集群监 报
控制集群运维控制集群运维
控 警集群监 报控 警集群监 报 控 警集群监 报控 警集群监 报
控制集群运维控制集群运维
控 警集群监 报控 警集群监 报
控制集群运维控制集群运维
控 警集群监 报控 警集群监 报
控制集群运维控制集群运维
控 警集群监 报控 警集群监 报
容灾指 集群挥容灾指 集群挥 控制集群运维控制集群运维
控 警集群监 报控 警集群监 报
控制集群运维控制集群运维
控 警集群监 报控 警集群监 报
容灾指 集群挥容灾指 集群挥 容灾指 集群挥容灾指 集群挥 控制集群运维控制集群运维
控 警集群监 报控 警集群监 报
控制集群运维控制集群运维
控 警集群监 报控 警集群监 报
- 40. 示:千万 在 的 技启 级 线 关键 术
外提供高可用性的服对 务
内提供高可 性的系对 运维 统
灰度 布发
控运营监
容灾
自 化运维 动 / 半自 化动
高可用性;高可 性运维
- 42. 1.4 在 背后的故事亿 线 (2)
科技(深圳)有限公司腾讯
即通平台部高 技级 术总监 icezhuang
——QQ IM 后台架 的演化与 示构 启
- 44. 随着 代的接近,新 又来了亿时 烦恼
活性:灵
“ 昵称” 度增加一半,需要 个月长 两
增加“故 ”字段,需要 个月乡 两
最大好友数从 500 成变 1000 ,需要三个月
代的重要能力:亿时
上万好友
私权限控制隐
PC QQ 与手机 QQ 互别 踢
微信与 QQ 互通
地容灾异
IM 后台从 1.0 到 3.5 都是在原来基 上做改造升 ,但是:础 级
持 打 丁已 以支 在续 补 经难 撑亿级 线
IM 后台 4.0 必 从 始,重新须 头开 设计实现
!
太差!
想都 想!别
- 47. IM 后台 4.0 存 系 成果储 统
历时 3 年完成
千万 好友级
私权限控制隐
活 展字段灵 扩
高可 性运维
操作 件化运维 组
自 移负载 动转
高性能
自写存储层
- 51. IM 后台 4.0 通信系 段成果统 阶
历时 2+ 年完成
多点登录
支持 5 至 10 个 例同 在亿 实 时 线
方便接入微信等多种业务
区域自治
高可 性运维
物理架 到机架构详细
故障分析智能化
- 52. 示: 在 的 技启 亿级 线 关键 术
提供高 活性的 支持灵 业务
传统 IT 行 可以半年到 年出一个新版本业 两
互 网行 要求每个月出一个新版本联 业
同 保持高性能、高可用性、高可 性时 运维
高性能;高可用性;高可 性;高 活性运维 灵
- 53. 腾讯 IM 服 的未来之路务
全球化分布
高效率的研发
控告警的智能化监
- 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 模型 全网 度调 灰度升级
保过载 护 立体 控监 自 部署动 柔性可用
大系 做小统
先扛住再 化优
重 生活边 构边
干干净净
有 服损 务 动态运营
Editor's Notes
- 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时,每周扩容两次,感觉自己都不是程序员了。而且又担心配置错误导致事故。
时不时要紧急恢复服务:几乎每人每周都要紧急处理一两次设备故障。
- 这页只是说一下发现了四方面的问题,不具体解释,后续会一个一个分析和解决
- 只在一个IDC内是没前途的
- 本页不展开各种模式的具体含义,只说需要达到什么目标。具体模式的含义后面几页说。
- 详细解释
- CPU100%的故事:一个小特性没写好代码,100% CPU,收到用户投诉才发现异常
- CPU100%的故事:一个小特性没写好代码,100% CPU,收到用户投诉才发现异常
- 这是后台监控系统上截取到的两个示例图,我们对各个维度、各种指标都有监控和告警
- 这是QQ群消息量的一天曲线,中间有个飙升。从时间上猜猜和什么事情有关系?
2008年8月18日 刘翔退赛后,群下发消息量
- 一个图,有最大值、最小值、波动值报警
- 一个子系统的监控视图,包括了数百个上一页的图片
- 整个IM后台,有上千个视图
总共,有十万个以上的图片和报警
- Grandy的故事:grandy修改配置表,要先写好where子句再写前面的语句。
- 服务可用性从原来的2个9提升到了4个9接近5个9,与google同级。
- 略讲,强调两套、有容灾指挥中心,且在两个IDC
- P15,画一下conn进程划分的图
- 看时间充裕度
- 详细解释
- 强调一下复杂性
- 强调一下是分布到不同的城市
- 详细解释
- 做一个万级在线的IM很容易,做一个亿级在线的IM很难
- IT成本是互联网企业生死存亡的决定性因素。
- 互联网行业是新兴行业,服务的架构设计和开发运营没有前车可鉴,腾讯作为互联网行业中不可或缺的企业,在这一块积累了行业内领先的体系化的设计/运营哲学,我们称之为海量服务之道。 从下到上一次是:价值观、意识、方法