微博与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命中率会很高。