这两天在Qcon的群里讨论im讨论的比较多，翻出11年写的一篇blog（略显稚嫩？），原文如下：
=====
在网上看了一篇关于微博feed系统的架构文章（SK：可能是2010年timyang在Qcon上的分享，又好像是一篇关于推拉模式的文章），有所感想，由于自己是做IM系统的，故自然会将两者的方案进行联想和对比。
feed系统
可以理解为一个发布订阅系统，你关注了姚晨的微博，姚晨发布了消息，会feed给你。
IM系统
即时通讯系统，典型系统为QQ。
实现方式
（1）推送
IM消息 就是一个典型的推送系统，服务端会主动将消息推送给客户端；
IM消息 实时性比较强，而微博的实时性相对不这么强，别人发的信息，订阅者晚个几分钟，甚至十几分钟收到都无所谓；
IM群与微博 有共同点：一个人发布一条群消息，推送给群内的其他成员；
IM群与微博 的不同点：群人数有限，而姚晨被500W人关注，消息扩散级别不在一个数量级；
如果使用推送来实现feed系统的话，姚晨发布一条消息，就要推送给500W个人，这个量级的扩散是不能接受的。
（2）拉取
IM系统消息（就是登陆QQ广告那种消息） 与微博 的共同点：系统消息需要推送给所有IM用户；
IM系统消息 与微博 的不同点：系统消息频率很低，可能每天几条，可微博发送频率很高；
IM系统消息的实现：不会对所有IM用户进行扩散，而是在用户登陆后，轮询拉取，例如10分钟一次。
系统消息实时性和微博类似，有个十几分钟延时也无所谓。
微博压力和IM系统消息压力不在一个数量级：
不妨设微博同时在线为1000W（指在浏览微博网页的），平均每人在线时长为1小时，每天需要轮询次数为：
1000w * 60分钟 / 10分钟一次 = 6000w次
一天4w秒算，每秒压力2k的QPS
不知道我是不是算少了，感觉应该能搞定。
（3）按时间优化拉取
热门微博与热门群消息，都可以按照时间对消息进行分级来优化，例如：
1小时消息表；
1天消息表；
1周消息表；
1月消息表；
可以针对每个级别的消息，做不用策略的存储或者cache。
最活跃的表，查询次数最多的表肯定是时间上最近的表，cache命中率会很高。
