关于类微博的timeline的设计思考

公司要开发一个类webio的系统,一个很基本的功能就是timeline。用户在自己的主页可以看到其观注的所有用户发表的信息列表;而其它用户可以一个用户的个人主页看到这个人发布的信息列表。

这时候最主要要考虑的就是采用推模式,还是拉模式。

一、推模式,以空间换时间;一个用户发布一条新信息之后,把这条信息追加到所有的粉丝的页面信息流里;这样当一个用户登录之后,通过一条fetch命令,就可以看他关注的所有人发布的信息了。但是这样一来,所带来的各种问题接踵而至:

1. 新关注一个用户时,需要把被关注的用户的所有历史数据都放到粉丝的数据流存贮里,在长时间后这是一个非常长的操作;

2. 取消关注一个用户时,需要把被取消关注的用户从原粉丝的数据流存贮里全部删除掉,这是一个O(N)的操作,而这个N的增加会很大;

3. 当一个用户删除一个已经分享的时候,需要将他的所有的粉丝的数据流里的这条记录都删除;

4. 一个用户的粉丝数是不受限制的,所以如果一个人的粉丝数过多的时候比如有1W个粉丝,那么发一条新消息,就要分解成1W次处理逻辑,工作量十分庞大。

 

所以就目前来看,不应该使用推模式,推模式带来的“坑”太多;

二、拉模式,空间消耗减小,时间消耗增加。 每个用户只存一个自己的timeline, 当一个用户打开自己的主页的时候,会把他关注的所有用户的数据取过来,然后进行合并,因为两个原因:1. 用户的数据存在redis里,存取速度十分快;2. 一个用户关注的用户数目是有限的(限制200人);

 

但是这时候存在的问题是,随着一个用户发的消息越来越多,用户的消息列表数据会越来越长,这时候merge所有一个用户关注的用户的信息过程会耗时非常长,而且消息列表数据长的时候,大数据网络传输也会特别耗时。

 

所以我认为在拉模式下,主要要修改用户发布的消息在redis里存贮的方式;

我的意见是在redis里以如下形式存贮:

userid_datetime –> user message list

即redis为每个用户存贮了每天的消息列表,这样就可以细化数据的粒度,减少每次取数据的数据量。

如此一来:

1. 当一个用户打开自己的主页的时候,只需要取他关注的用户当天的消息列表,这样的话取的数据量就会少很多,大大减少数据的传输和合并时间;如果当天数据不足,考虑再取前一天的数据;

2. 当打开一个用户的个人主页的时时候,可以考虑取最近10天的数据,不足的时候再动态加载。

 

而在页面展示的时候,可以突出时间的分隔点:

每天和每天的数据之意加一个突出的时间分隔符:

-----------> xxxx.xx.xz <------------------

-----------> xxxx.xx.xy <------------------

这样可以让用户非常直观的感觉到一个用户的数据发布时间轴,以及自己关注的用户的活动时间轴。

 

个人的一些观点。

posted @ 2013-03-18 22:23  傲行人生路  阅读(1967)  评论(1编辑  收藏