编码随笔

大型网站的Timeline设计

    大型的网站中,为了保持用户之间的社交热度,常常使用Timeline模式,以Twitter,新浪微博为例,其核心问题都是如何处理巨大的消息分发。如有1000万的用户,平均每个用户有100的粉丝,每天每个用户平均发送2条消息,那么每天要处理的基本消息就有1000万*2=2000万条,推送消息有1000万*100*2=20亿条。

    如何处理如此大的数据呢?“推Push”和“拉Pull”或者“推拉结合”,是主要的处理方式。技术方面主要包括缓存redis/memcached,数据库mysql等,检索引擎lucene等,本文不涉及网络流量的处理。

    缓存技术,我推荐使用redis。一直以来,我十分喜欢使用redis,很多业务中,我都用到了redis,相比较于memcached,redis提供了更多的数据结构,如list,Sorted-Sets等,而不仅仅只是key-value的结构,所以它能够处理复杂的业务逻辑,当然不同的数据,对于缓存占用是有很大差别的,同样的数据list存储和sorted-sets存储,后者占用的内存可能是前者的一倍或是更多。 所以,在数据结构的使用方面,一定要根据自己的业务,选择最合适的数据结构,尽量占用更小的内存,使之运行的更快。当然redis也有自己薄弱的地方,对于持久化这一点,如果redis要实现自身的数据持久化,往往要消耗数据两倍的内存,就是你实际数据有10g,那么加上持久化则会一共占用20g的内存,so,我推荐不在redis不做持久化,数据持久化在数据库中。

    数据库方面倒是没有特别的推荐,每个团队有各自使用的关系型数据库,mysql/oracle或是hdoop,甚至某云平台,能够用好即可,尽量少的字段,尽量小的数据,最快的索引结构,想要运行的更快,就需要更好的数据结构,更合适的业务逻辑。

    检索引擎,推荐使用solr,简单强大,由于此处只是为了Timeline的模型考虑,索引中只存储关系人的id,消息的id等检索字段,不涉及到分词,所以不深入讨论。

    综上,大概就是下面的架构图:

    需要注意的还有几点,多统计实际消耗的内存,同时在线的用户量,每天处理的实际消息数,根据实际情况调整运维方案,及时扩充内存。长期不登录用户,缓存要及时清理,缓存中可以只存储登录用户近期的推送数据,查看历史数据时,临时扩充缓存,并及时销毁。

    暂时就这么多了,后续有空再写的别的。

by will,2015

签名: