探讨微博时间流的实现

微博feed系统的推(push)模式和拉(pull)模式实现timeline

推拉结合

推数据和拉数据都有什么优缺点？在用户的信息流中，推数据的实现其实更简单。姚晨发了条微博，只需要取出姚晨粉丝的信息流，依次推给粉丝就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交互的动作。

总结：

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

文章为原创，转载请注明链接地址。觉得有帮助的话，不妨打个赏吧!

参考文章：

1. 冷数据、温数据、热数据，难道数据也是有温度的？
2. 浅谈如何定义活跃用户