Feed流实现

三种实现方式

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

1.写扩散

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

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

2.读扩散

用户发表作品时，将作品接入发布者的outbox

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

3.推拉结合

思路是部分场景使用推，部分场景使用拉的方式

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

 

推拉结合的实现

这种实现就是怎么区分什么时候用推的方式，什么时候用拉的方式。这个场景有几种区分的方式

1、对在线用户使用写扩散的用户，每个维护一个timeline list。离线的用户还是得拉的方式，这里有个体验的优化，在用户点入APP时，后台开启线程提前拉取好动态timeline list。用户真正访问动态时，直接返回改list就好

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

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

 

我们具体的做法

实际是个读扩散

给每个person维护一个zset,是个人发表作品id，时间戳排序

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

每次获取动态：

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

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

3、用user_feed_ts筛选出给用户推的feed

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

 

 

参考：

https://www.zhihu.com/question/19645686

https://www.cnblogs.com/daizhj/articles/3545343.html

https://yq.aliyun.com/articles/224132

还有微博缓存的设计ppt

https://www.slideshare.net/iso1600/cache-4842490?from=ss_embed