关注推荐Feed流
关注推荐服务
与推荐feed流有所不同，关注推荐服务所用到的视频池是根据用户的关注列表得到的，而不像feed流，使用的是整个的媒资库的视频池。
app实现的关注推荐feed类似于新浪微博的时间流乱序列表，但是根据业务场景又有所不同。
关注列表视频池存储方式
APP用户关注不同的up，up下有众多生产的视频，用户从而有一个关注池。
用户获取关注池的方式无非有两种：pull模式，push模式。
详尽的两种方式的介绍网上有很多，我发现有几篇文章写得很不错、易懂的，如下：
我采用的是使用推的模式。
即当up生成出的视频通过了审核被允许加入到用户的关注列表之后，这则视频将会进入up所有粉丝的关注列表。当一则视频被up或者运营审核人员删除之后，会从up的所有粉丝之中移除。
关注推荐服务架构
存储与存储逻辑
存储方面主要有四个库：关注池落地库MySQL，红点库redis，关注推荐结果库redis，用户关系库redis
1. 落地MySQL库
MySQL中存储的是用户的关注的视频，其中某一个用户的关注池的一条视频就是MySQL中的一条记录。
落地库记录的是全量的视频记录，所以用户的新增关注、取消关注、视频被删除、视频隐私状态被改变、关注的up的视频新增都会反映到落地库中。即使没有其他三个库，用户也是可以获取到自己的关注列表的，但是是完全顺序的，如果不考虑红点等业务场景的话，这样一个库就能够满足需求了。
因为是全量库，所以如果有10w用户，每个人都关注池里有100条视频，那么MySQL中就会有1000w条记录。并且随着用户的新增，视频的新增，这个数目还会不断的累积。而且如果一个大V发布了一条视频，他拥有10w粉丝，那么发布这条视频的同时，就会产生10w条记录，这会带来数据库写突增的问题，以及数据库冗余数据存储的问题。
解决发布为：
- 将大V发布的视频，放入粉丝的关注池的视频，使用任务池的方式，缓慢的插入到粉丝的关注池中，即使粉丝的关注池没有更新到那么及时也是能够接受的。
- 数据冗余存储的问题，定期删除插入关注池时间较长的记录。比如某一条记录是30天以前进入关注池的，那么可以将这条视频删除。类似于新浪微博，也会有列表元素期限限制，很难刷出30天或者更久的视频。当用户的关注池为空、有关注关系、不为新用户时，说明这个用户可能很久没有新增关注了，并且他关注的up也很久没有发布视频。这样的情况可以去根据他的关注up列表拉取视频。但是目前线上没有这样做。因为这样的情况极少，如果出现了，用户的关注流没有视频，也希望展示空白页或者推荐页给他，希望他去新增关注。
2. 红点库redis
这边有一个业务逻辑是，需要将红点的视频放在关注列表的前面，并且这个优先级高于rank排序，并且当再次访问时关注列表时，顺序依旧不被改变。
所以当新视频进入关注池时，会被加入到红点池(落地库MySQL只要有关注列表更新都会更新)；当一个视频被删除，up被取消关注导致视频被移出关注池，会被移出红点库。
3. 关注推荐结果库redis
这个库存储经过排序关注列表，起到一个分页的效果，并且保证红点池的视频能够排在之前的视频前面。当一个视频被删除，up被取消关注导致视频被移出关注池，也会被移出结果库。
4. 用户关系库redis
用户关系库主要存储用户与up的互动关系，其中有用户对up的互动详细数据，在排序阶段从这个库获取数据，并且计算视频得分，进行打分排序。
Extra
需要注意的是，由于留存率的原因，大部分用户来过平台之后，就不会再来，但是还是会为他保留这四个库其实是存在很大浪费的。
其中可以使用一些方法，减少浪费。
比如推荐结果库设置一定的失效时间，用户长久不更新结果库，那么会失效，当用户再次请求的时候，会直接从落地的全量MySQL库拉取数据，并且删除红点库对应的数据。
红点库也是浪费的主力，在往红点库新增数据的时候，可以检查一遍结果库是否有值，如果无值那么就没有必要更新。因为结果库无值，用户请求时，也不会需要红点库等数据。