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亿级
高性能；高可用性；高可运维性；高灵活性
只实现功能，不难
高性能/低成本
高可用性
高可运维性
高灵活性
很难！
在线量每提升一个量级，技术难度也提升一个量级
从下到上一次是：价值观、意识、方法