QQ IM架构学习总结

今天学习了腾迅的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亿级
 高性能；高可用性；高可运维性；高灵活性


 只实现功能，不难
 高性能/低成本
 高可用性
 高可运维性
 高灵活性
 很难！
在线量每提升一个量级，技术难度也提升一个量级





从下到上一次是：价值观、意识、方法