你在朋友圈、小红书首页、微博里不断往下刷，永远刷不到头的内容列表，就是 Feed 流。实现一个高性能的 Feed 流，是所有大型互联网社交产品后端架构重中之重的难题。
📚 实战篇 07. 好友关注 - Feed 流实现方案分析
一、 什么是 Feed 流？
Feed 流（Feed Stream） 直译为“投喂流”，本质上是为用户持续提供内容的系统。
当你关注了 10 个博主，系统需要把这 10 个博主发布的最新笔记，按照时间倒序（最新的在最上面） 拼装在一起，推送到你的眼前。
Feed 流常见的实现方案有三种：拉模式（Pull） 、推模式（Push） 和 推拉结合模式（Hybrid） 。
二、 方案 1：拉模式 (Pull / 读扩散)
核心思想： 粉丝上线时，主动去“拉取”自己关注的所有人的动态。
-
工作流程：
- 博主（发件人）发布笔记，只把笔记存到自己的**“发件箱”**里。
- 粉丝（收件人）打开 App 首页时，系统去查粉丝关注了哪些博主。
- 系统去这几十个博主的“发件箱”里，把他们最近的笔记全部拉取过来。
- 在内存中按照时间进行大排序，最终展示给粉丝。
-
优点：
- 节省空间： 一篇笔记只存一份，不冗余。
- 发件极快： 博主发完笔记就结束了，不用管粉丝有多少。
-
致命缺点：
- 读延迟极高（读扩散）： 每次粉丝上线都要经历“查关注列表 -> 拉取海量发件箱 -> 内存大排序”的漫长过程。如果关注了 1000 人，数据库瞬间崩溃。
三、 方案 2：推模式 (Push / 写扩散)
核心思想： 博主发动态时，系统主动把动态“塞”进所有粉丝的收件箱。
-
工作流程：
- 系统为每一个用户分配一个专属的**“收件箱”（通常用 Redis 实现）**。
- 博主发布笔记后，系统查出该博主的所有粉丝。
- 系统像发传单一样，把这篇笔记的 ID，循环复制，直接写入每一个粉丝的“收件箱”里。
- 粉丝打开 App 时，只需要读自己专属的“收件箱”即可，直接拿到排好序的数据。
-
优点：
- 读性能极度强悍： 粉丝读取时没有任何复杂的查询和排序，直接从自己的 Redis 收件箱拿数据，时间复杂度 。完美契合“读多写少”的社交场景。
-
致命缺点：
- 极其浪费空间（写扩散）： 一篇笔记如果有 1 万个粉丝，就要复制 1 万份。
- 大 V 灾难： 如果某顶流明星有 5000 万粉丝，发一条动态，后台要向 5000 万个 Redis 收件箱里写数据。服务器会因为发送这 5000 万条消息而瘫痪，这被称为**“大 V 宕机效应”**。
四、 方案 3：推拉结合模式 (Hybrid / 智能折中)
这是目前微博、微信朋友圈等亿级大厂普遍采用的终极架构。
核心思想：针对不同量级的博主和不同活跃度的粉丝，看人下菜碟。
-
对于普通博主（比如只有几百几千粉丝）：
- 直接采用推模式。因为粉丝少，写扩散成本极低，优先保证粉丝的极速阅读体验。
-
对于大 V / 明星（比如千万粉丝）：
- 采用推拉结合。
- 大 V 发动态时，只把动态推（Push）给最近几天频繁登录的活跃粉丝的收件箱。
- 对于几千万的僵尸粉/不活跃粉丝，什么都不推。
- 当那些不活跃粉丝某天突然心血来潮登录 App 时，系统再使用拉模式（Pull） ，主动去大 V 的发件箱里拉取最新动态。
五、 黑马点评项目的架构选型
黑马点评作为一个处于成长期的 O2O 探店项目，用户的关注量通常不会像微博那么夸张（很少有千万级大 V）。
- 选型决定： 为了保证用户极致的访问体验，我们将采用纯粹的 推模式（Push） 。
- 技术底座： 由于用户的 Feed 流必须按时间严格倒序排序，而且需要频繁的读写操作，我们将毫无疑问地再次使用 Redis 的 SortedSet (ZSet) 作为每个用户的“收件箱”。（Score 存时间戳，Value 存笔记 ID）。
学习总结
面试官如果问你：“为什么你们的 Feed 流要用推模式？”
你可以这样降维打击：
“因为我们的产品形态类似于朋友圈，属于‘读极多、写相对较少’的场景。采用拉模式会导致读取时触发大量的聚合排序计算，带来不可控的读延迟。虽然推模式会有存储冗余，但我们利用 Redis ZSet 作为收件箱，用极小的内存代价（只存笔记 ID 和时间戳）换取了用户首页 的极致拉取速度。至于大 V 问题，未来量级上来后，我们会演进为推拉结合的架构。”
