40 | 信息流设计（二）：通用信息流系统的拉模式要如何做？

唐扬



该思维导图由 AI 生成，仅供参考

你好，我是唐扬。
在前一节课中，我带你了解了如何用推模式来实现信息流系统，从中你应该了解到了推模式存在的问题，比如它在面对需要支撑很大粉丝数量的场景时，会出现消息推送延迟、存储成本高、方案可扩展性差等问题。虽然我们也会有一些应对的措施，比如说选择插入性能更高的数据库存储引擎来提升数据写入速度，降低数据推送延迟；定期删除冷数据以减小存储成本等等，但是由于微博大 V 用户粉丝量巨大，如果我们使用推模式实现信息流系统，那么只能缓解这些用户的微博推送延迟问题，没有办法彻底解决。
这个时候你可能会问了：那么有没有一种方案可以一劳永逸地解决这个问题呢？当然有了，你不妨试试用拉模式来实现微博信息流系统。那么具体要怎么做呢？
如何使用拉模式设计信息流系统所谓拉模式，就是指用户主动拉取他关注的所有人的微博，将这些微博按照发布时间的倒序进行排序和聚合之后，生成信息流数据的方法。
按照这个思路实现微博信息流系统的时候你会发现：用户的收件箱不再有用，因为信息流数据不再出自收件箱，而是出自发件箱。发件箱里是用户关注的所有人数据的聚合。因此用户在发微博的时候就只需要写入自己的发件箱，而不再需要推送给粉丝的收件箱了，这样在获取信息流的时候，就要查询发件箱的数据了。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文介绍了信息流系统设计中的拉模式和推拉结合模式的方案。拉模式通过用户主动拉取关注的人的微博，解决了推模式存在的问题，如推送延迟、存储成本和功能扩展性。作者提出了针对拉模式存在的问题的解决方案，包括优化缓存存储策略和使用缓存副本来分摊带宽压力。另外，推拉结合的模式通过只推送活跃的粉丝用户来解决推模式的问题，但也带来了维护成本。文章还提到了在项目中使用拉模式实现信息流系统时可能遇到的问题以及解决方法。总的来说，本文为读者提供了关于信息流系统设计中拉模式和推拉结合模式的方案，以及在方案设计过程中可能遇到的问题和解决方法。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《高并发系统设计 40 问》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(31)

最新
精选

👽
推的概念近似于邮箱，杂志提供商，把杂志直接投到每订阅用户的邮箱里；拉的概念类似于广告牌，广告商只把自己的广告挂出来，而用户端来获取自己想看的广告内容；起初用户量小，微博删除不频繁，可以用推。让邮递员挨个去送就好。随着用户体量增大，邮递员跑步过来了。于是干脆直接改用广告牌的形式，直接发布，谁爱看谁看。另外，就业务与现实中的例子的考量，个人认为拉更合适。因为收件箱的概念，只适用于不频繁的修改。类似于邮件，发到你邮箱里就是发到了。而微博，发到你收件箱了，如果删除了，还得从你收件箱里把邮件拿出来。就不是很合理。
作者回复: 是的，微博的场景用拉比较合适
2020-02-24
2
15
小白哥哥
“如果活跃粉丝数量超过了长度，就把最先加入的粉丝从列表里剔除”，这块是不是会有问题。最先假如的活跃粉丝很可能一直是活跃的，因为长度有限的原因就把他挑出来会不会不太好。
作者回复: 剔除了无非就是无法实时获取到消息，但是他还是会被加入到活跃粉丝列表中，而且，在刷新信息流的时候可以拉取大V的发件箱做数据补偿
2019-12-25

12
QQ怪
这两篇真的实践出真理，好厉害老师
作者回复: 谢谢，我只是站在前人的肩膀上😂😂
2019-12-25

7
旅途
老师有两个地方没懂希望能解答下 1.缓存副本 100m缓存了60% 使用了60m带宽 ,主缓存消耗剩下40%就是40m带宽这样的话加起来不还是100m带宽吗 2.推拉模式的例子,只有活跃用户是实时推送,不活跃用户异步推送,这样的话不是都使用的推模式吗？
作者回复: 1. 但是每一个缓存的带宽降低了 2. 不活跃用户是不推送，但是不活跃用户上线后会拉取发件箱，所以叫推拉结合
2019-12-25
3
5
flycun
干货满满
作者回复: 谢谢🙏
2020-04-05

4
nestle
请问缓存中只放微博ID，实际内容还要去DB查吗？
作者回复: 当然了~
2020-02-03

3
南山
春节把整个专栏理了一边，收获颇多，非常喜欢老师的实际案例的分享，结合理论，每篇都都值得细读借鉴。后续希望有机会应用于实际工作！
作者回复: 谢谢~
2020-01-28

2
zenk
干货，深感老师功力深厚
作者回复: 谢谢🙏
2020-03-25

1
gyun
“在拉模式下只保留了发件箱，微博数据不再需要复制，成本也就随之降低了。”如果谢娜发送了一条微博，1.2亿粉丝中有2千万是活跃粉丝，其中3百万正在刷feed，单个node肯定扛不住这么高的读请求（因为是同一个热key）。那么只能用多个副本来解决分担了。但是假设一个副本能扛住10万读请求，那么岂不是要30个副本来抗？而且一个node上可能有多个热key存在。望老师赐教。
作者回复: 其实并发不会到单个节点300万，一般整体核心缓存几十万的qps就差不多了
2020-03-21

1
Li Yao
为什么必须用缓存副本，而不是水平扩容主缓存的方式来缓解网卡压力呢？
作者回复: 扩容主缓存会造成命中率下降，并且同一组缓存节点数不能过多
2020-03-09
3
1

收起评论