今天学习了腾迅的ppt分享《1.4亿在线背后的故事》,tecent技术果然是很NB的,对ppt进行了精简总结,以备不时之需。
10万-百万的演变
在线状态的获取
1.定期拉取
2.实时通知
实时通知的3种方式,各有什么优缺点?
直接发包:最简单,但是不能应对某些NAT,也不能应对TCP接入。
伪装IP发包:编程难度大,可以应对NAT,但是不能应对TCP接入,有时还会被IDC自己的网络设备拦住。
通过真正的接入服务器发包:可以应对所有情况,但是成本高。
所以实际演变的顺序就是上面的顺序
QQ后台如何实现高性能
绝不使用企业级解决方案
逻辑层多进程
万有一失的无锁设计
用户态IPC
MySQL分库分表
好友表自写文件存储
绝不使用企业级解决方案:Google牛人的话。
万有一失的无锁设计:通过业务流程的巧妙设计来避免使用锁。举例:设置隐身可见(状态进程)与加好友(好友进程)的冲突没关系;但是LocalOnlineRecord中对好友表位置指针的修改只有登录进程能做。
用户态IPC:使用共享内存设计出用户态的FIFO
QQ后台如何实现7X24小时连续服务
大系统小做
平滑重构
在高速行驶的列车上更换发动机
核心数据放入共享内存
接入层与逻辑层分离
命令分发动态配置化
百万-千万的演变
发生现象:
手机从不敢离身
发布新代码提心吊胆
时不时要扩容,又烦又怕
时不时要紧急恢复服务
时不时被用户骂、被老板K
到底怎么了?
原因:
1.后台机器越来越多,单机死机/故障经常出现,IDC故障也不少,影响服务,也影响人员生活
a) 传统行业设备少单价高,故障很少出现
b) 互联网行业设备多单价低,故障是常态
c) 只在一个IDC内是没前途的
容灾改造的思路
存储集群:半自动切换模式
主/从服务器
从服务器死机,业务不受影响
主服务器死机,多数命令不受影响,修改资料命令受影响
业务集群、接入集群、同步集群:自动切换模式
迅速应对死机等情况,基本不影响业务
分布在两套IDC
可以应对IDC整体故障
2.每周有新代码发布,BUG不断出现,严重影响服务
大部分子系统每周发布一个版本的新代码
解决方法
代码review
灰度发布(每天只发布部分特性)
3. 监控机制原始、报警设置不全,出事了都不知道
CPU 100%的故事
解决方法
完善监控和报警
4. 运维操作通过vim或者mysql进行,非常容易失误
Grandy的故事
解决方法
运维操作Web化(半自动化)、自动化
强调两套、有容灾指挥中心,且在两个IDC
千万级在线的关键技术
对外提供高可用性的服务
对内提供高可运维性的系统
灰度发布
运营监控
容灾
运维自动化/半自动化
亿级在线的关键技术
存偖架构
提供高灵活性的业务支持
传统IT行业可以半年到两年出一个新版本
互联网行业要求每个月出一个新版本
同时保持高性能、高可用性、高可运维性
QQ IM后台技术演化的启示
1.0十万级、2.0百万级
高性能;7乘24小时连续服务
3.0千万级
高可用性;高可运维性
4.0亿级
高性能;高可用性;高可运维性;高灵活性
只实现功能,不难
高性能/低成本
高可用性
高可运维性
高灵活性
很难!
在线量每提升一个量级,技术难度也提升一个量级
从下到上一次是:价值观、意识、方法
QQ IM架构学习总结
最新推荐文章于 2023-12-20 14:24:29 发布