场景解剖二：Feed 流
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 7 · 亿级场景实战 · 第 40/49 篇 · 🚧 占位待学
上一篇：《场景解剖一：IM 消息系统》
下一篇：《场景解剖三：千万长连接推送系统》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 7 · 单元 7.2
一、本文要解决的问题
明星官宣，千万粉丝的收件箱怎么更新？Feed 流的本质矛盾：写扩散让读飞快（发布时把消息推进每个粉丝收件箱）但大 V 发布是灾难；读扩散让写轻松但每次刷新都要现场聚合。工业界的答案是推拉结合 + 收件箱裁剪。
二、知识点清单
- 推模式（写扩散）：发布时 fanout 到所有粉丝收件箱——读 O(1)，写 O(粉丝数)；普通用户适用
- 拉模式（读扩散）：发布只写自己发件箱，刷新时现场合并关注人的发件箱——写 O(1)，读 O(关注数)；大 V 适用
- 推拉结合：普通用户推、大 V 拉，在线粉丝推、离线粉丝拉——切换阈值（粉丝数 / 在线率）
- 收件箱裁剪：固定长度（如 1000 条）+ 超出部分回源拉取，控制存储与扇出成本
- Timeline 合并：多路归并排序（按时间）、去重（同一条内容被转发多次）
- 计数异步化：点赞 / 评论计数不阻塞发布链路，走 MQ 异步累加
三、动手实验（学习时必须真跑）
- 实现简化 Feed：关注关系表 + 发件箱 + 收件箱，发布与刷新两个接口
- 推与拉两种实现各压测一遍：对比发布延迟（普通用户 vs 万粉大 V）与刷新延迟
- 实现推拉结合版 + 收件箱裁剪（固定 200 条），模拟万级粉丝发布验证扇出可控
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。