设计微博系统

设计微博系统

架构

信息流聚合一般有三种架构:推模式拉模式以及推拉结合

针对关注的粉丝量大的用户采用拉模式,而对于一般用户来说,他们的粉丝量有限,采用推模式问题不大,这样的话一个用户要获取所有关注人的微博,一方面要请求粉丝量大的关注人的发件箱列表,另一方面要请求自己的收件箱列表,再把两者聚合在一起就可以得到完整的 Feed 了。虽然推拉结合的方式看似更加合理,但是由此带来的业务复杂度就比较高了,因为用户的粉丝数是不断变化的,所以对于哪些用户使用推模式,哪些用户使用拉模式,维护起来成本就很高了。所以综合考量下来,微博 Feed 采用了拉模式

前面提到采用拉模式的话,需要拉取所有关注人的发件箱,在关注人只有几十几百个的时候,获取效率还是非常高的。但是当关注人上千以后,耗时就会增加很多,实际验证获取超过 4000 个用户的发件箱,耗时要几百 ms,并且长尾请求(也就是单次请求耗时超过 1s)的概率也会大大增加。为了解决关注人数上千的用户拉取 Feed 效率低的问题,我们采用了分而治之的思想,在拉取之前把用户的关注人分为几组,并行拉取,这样的话就把一次性的聚合计算操作给分解成多次聚合计算操作,最后再把多次聚合计算操作的结果汇总在一起,类似于 MapReduce 的思路。经过我们的实际验证,通过这种方法可以有效地降级关注人数上千用户拉取 Feed 的耗时,长尾请求的数量也大大减少了。

存储

UID range 作为分片

UID hash 作为分片