如何设计一个微博feed流( 二 ) _feed流

3. 数据状态同步
当被关注用户删除微博或取关某博主时，需要将所有粉丝的收件箱中的内容都删除，依然存在一个写扩散的即时性问题
可尝试的解决方案：
在拉取数据的时候对微博的状态进行判断，过滤已删除/已取关的微博过滤

以上解决方案可以在一定程度上提升效率，但是不能根源上解决问题。
3）小结
推模式仅适用于粉丝量不会太多的情况，例如微信朋友圈，这样能够比较好的控制好即时触达性、以及数据存储的成本。
对于微博大V这种粉丝量很大的场景并不适合。
4. 使用拉模式
拉模式也称读扩散模式，当我们使用拉数据的方式后，用户获取数据流程如下：

获取所有关注的博主ID 。

select liker from t_like where userId = 1;
2. 根据博主ID进行内容拉取。
select * from t_feed where userId in (4,5,6) and recordStatus = 0;

获取所有内容后根据timeline进行排序。

这样的方案解决了在推模式下存在的三个问题，但是却也引发了另外的性能问题。
假如，用户关注的博主非常多，要拉取所有内容并进行排序聚合，这样的操作必定会耗时很多，请求时延很高。
那么如何做到低耗时，完成快速响应呢？
单纯依靠数据库是无法达到要求的，所以我们要在中间引入缓存层（分片），通过缓存来降低磁盘IO 。
1）流程为：

关注列表缓存

将用户关注的所有博主ID存入缓存中。以用户ID为key ， value为关注博主id集合

微博内容缓存

以博主ID为key ， value为微博内容集合。博主发布微博后，将微博内容存入集合中

获取feed流时

根据关注的博主id集合，在所有缓存分片节点上拉取所有内容并进行排序聚合。
假如缓存分片集群为三主三从，也就是一共需要三次请求即可拉取到所有内容，然后进行时间倒排，响应给用户
2）存在的问题

系统的读压力很大

假如用户关注了1000个博主，那么需要拉取这1000个博主的所有发布内容，进行排序聚合，对于缓存服务，以及带宽压力都很大。
可尝试的解决方案:
缓存节点一主多从，通过水平扩容，来分散读压力和带宽瓶颈
3）小结
对于大V用户，拉模式能够很好解决写扩散存在的问题，同时也会带来上述存在的问题。
三. 总结
分析完推模式和拉模式的优缺点，我们很容易发现

推模式适合于粉丝量不大的场景。例如朋友圈，一对一聊天。
拉模式适合粉丝量巨大的大V用户。例如微博大V 。

所以在场景设计时，可以将推模式和拉模式结合使用。逻辑如下

设定一个大V粉丝量阈值，达到阈值后触发打用户标签事件。
对于未达到阈值的用户依然使用写扩散方式，这样冗余的数据量不会太大，也不存在即时性问题。
当达到阈值的用户发微博的时候，将微博内容存入缓存（热数据），不进行写扩散，而是粉丝拉取数据与收件箱中的数据进行排序聚合。

PS：这里还可以通过用户行为去维护一个活跃粉丝列表，对于该列表中的粉丝，同样进行一个写扩散的行为，保证即时触达。
IT架构师/技术大咖的交流圈子,为您提供架构体系知识、技术文章、流行实践案例、解决方案等，行业大咖分享交流/同行经验分享互动,期待你的加入!扫码即可加入哦，随着材料不断增多社群会不定期涨价早加入更优惠