feed

Feed流实现

三种实现⽅式

feed流实现按分类来说有三种

1.写扩散

⽤户发表作品时，后台给每个粉丝的inbox发送消息（inbox⼀般是个list，发布时间排序）,

缺点是对于⼤V账号，⼀次性推上千万对内存、计算资源消耗，以及对实时性有影响

2.读扩散

⽤户发表作品时，将作品接⼊发布者的outbox

⽤户拉取动态时，去每个关注⼈拉取outbox的内容，缺点是当关注⼈多的时候，拉取的代价太⼤

3.推拉结合

思路是部分场景使⽤推，部分场景使⽤拉的⽅式

⽆论哪种⽅式，客户端请求的时候带上次的时间戳（或者服务端保存这个时间戳），然后通过时间戳来拉取新动态

推拉结合的实现

这种实现就是怎么区分什么时候⽤推的⽅式，什么时候⽤拉的⽅式。这个场景有⼏种区分的⽅式

1、对在线⽤户使⽤写扩散的⽤户，每个维护⼀个timelinelist。离线的⽤户还是得拉的⽅式，这⾥有个体验的优化，在⽤户点⼊APP时，

后台开启线程提前拉取好动态timelinelist。⽤户真正访问动态时，直接返回改list就好

2、使⽤推的⽅式，只有对于⼤V⽤户，⽤户去拉⼤V的作品，然后做⼀次聚合，返回给客户端。推模式下避免了⼤V发作品⼤量写操作

3、区分粉丝的活跃度，发表新作品只对活跃的粉丝执⾏写操作

我们具体的做法

实际是个读扩散

给每个person维护⼀个zt,是个⼈发表作品id，时间戳排序

维护每个⼈上次看过的feed的最新时间戳（或者以客户端带上的时间戳）

每次获取动态：

1、获取关注⼈列表和上次看过的feed的最新时间戳ur_feed_ts

2、批量请求redis的zt,时间戳设为7天前，取出每个关注⼈7天内发表的feed的id

3、⽤ur_feed_ts筛选出给⽤户推的feed

4、再做其他业务过滤，组装好详情结果，返回给客户端

参考：

还有微博缓存的设计ppt