微博与im消息实现对比[随想]

这两天在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命中率会很高。

【完】

回复【架构】，阅读《58同城推荐系统架构设计与实现》

回复【youtube】，阅读《YouTube系统架构》

回复【赶集】，阅读《赶集mysql军规》

回复【同城】，阅读《58同城mysql实战（上）》

回复【数据库】，阅读《58同城数据库架构设计思路（下）》

回复【秒杀】，阅读《秒杀系统架构优化思路》（火）

回复【轮询】，阅读《webim如何用轮询保证消息绝对实时》（im）

回复【可靠】，阅读《webim如何保证消息的可靠投递》（im）

回复【twitter】，阅读《twitter系统架构分析》（想了解微博架构的看这个）

若有收获，感谢随手转发。