探讨微博时间流的实现

推拉结合

推数据和拉数据都有什么优缺点？在用户的信息流中，推数据的实现其实更简单。姚晨发了条微博，只需要取出姚晨粉丝的信息流，依次推给粉丝就OK了。拉数据的逻辑实现就非常复杂，需要获取所有我关注用户的动态，并对其进行整合，每次刷新、或者加载更多需要判断的逻辑就更多。

姚晨粉丝1000万，如果有1000万个姚晨同时更新了一条动态，数据要推到什么时候？假设这个情况真的发生了，那么首先肯定这是一个并行的操作，其次网络以及缓存那么快，再加上一些算法优化，我相信超过不了5分钟吧。而且给所有粉丝推数据也是不现实的。

为什么不是给所有姚晨的粉丝推数据？假设用户A关注了姚晨之后就再也没有玩过微博，在有限的内存空间维护用户A的信息流会变得毫无意义。所以推的对象应该是活跃的用户，或者是当天的在线用户。

用户信息流（Feed）构建

数据存储基于Redis的ZSet数据结构。ZSet优势非常明显：自动排序。信息流按照时间排序正是利用了这一点。为什么不考虑使用List，最基本的一点就是取消关注用户A（或者用户A删除了刚刚发的动态）之后，删除粉丝信息流中A的动态变得非常困难：一个可怕的遍历操作。

用户信息流该怎么创建？APP端用户对信息流有两个基本操作，下拉刷新和上拉加载更多。对于活跃用户，他的信息流都是推过来的，每时每刻都是最新的，所以只考虑数据显示逻辑就OK了。对于不活跃的怎么处理了，这个分支有点多？

如果用户A消失一周之后又想看姚晨的状态，怎么办？很显然用户A一下由僵尸粉变成了活跃粉，Redis里没有他任何的信息流数据（因为他消失的时间太久了），信息流需要完全重建。我们首先获取他关注的所有用户，假设为用户群B。筛选用户群B中今日更新动态的用户，然后合并信息流，依次类推。

如果用户A消失2天之后又想看姚晨的状态，此时系统已经停止了对他的实时推送，但是他的信息流却依然存在，只是缺少了（他的信息流中）最早动态时间到当前时间这段间隔的动态。重构该期间的动态。

综上所述：停止信息流实时更新的时间间隔、信息流过期时间、用户最后一次更新动态的时间都是需要认真权衡的。

区分冷热数据

也就是区分活跃用户和不活跃用户。活跃用户的几个属性：1. 用户最后一次发帖的时间；2. 用户最后一次登录的时间；3. 用户只查看不发帖；4. 用户今天是否在线。等等

如何衡量用户今日是否在线？需要找一个定义标准：用户今日浏览过、或者用户今日登陆过。本质上说就是找到一个：用户今日有过与APP交互的动作。

总结：

文中信息流和时间流混用，但是表示的是同一个意思。简单介绍了我对时间流的看法（只是我个人的认识，不知道微博具体是如何实现的）。大家认真看完了的话，就赶紧评论互喷起来吧。

注：博客迁移地址：https://segmentfault.com/a/1190000006667829

觉得有帮助，请打赏：