昨晚一个 6 年经验的粉丝在群里复盘字节跳动架构面，心态崩了。
面试官问了一个非常核心的业务场景题：“抖音/微博的‘关注流’（Feed Stream），用户发视频，粉丝刷视频。如果让你来设计这个系统，你怎么做？”
这哥们觉得这题熟，自信地回答：“这不就是消息通知吗？用**‘推模式’（Push）！每个用户维护一个 Redis List（收件箱）。A 发了视频，就遍历 A 的所有粉丝，把视频 ID 推送到粉丝的 List 里。粉丝读取时，直接查自己的 List，速度极快。”
面试官听完，冷笑了一声，追问： “推模式读确实快。但如果某顶流大V发了一条视频，他有 1 亿粉丝。 按照你的方案，你需要瞬间发起 1 亿次 Redis 写入。哪怕你用了 MQ 削峰、Redis Pipeline 批量写，写入延迟和资源消耗也是巨大的。 这意味着，该大V发了视频，粉丝可能要几分钟后才能看到，而且这期间 Redis 集群可能因为写热点产生抖动。这能上线吗？”
这哥们瞬间哑口无言，才意识到自己掉进了“写扩散”的深坑。
兄弟们，Feed 流架构 是大厂面试的“试金石”。 它没有标准答案，只有“最适合业务场景的取舍”。
今天 Fox 带你拆解这道题的 3 种段位，看看亿级流量的社交系统是怎么搭建的。
一、 为什么 “单纯的推/拉” 都是死路？
在设计 Feed 流时，我们面临两个核心概念：Inbox（收件箱）和Outbox（发件箱）。
纯拉模式（Pull / 读扩散）：
逻辑：大V发视频，只存自己的 Outbox。粉丝要看时，去遍历自己关注的 2000 个博主 的 Outbox，把最新视频拉取回来，在内存中排序。
死穴： 读延迟极高。 如果你关注了 2000 人，每次刷新都要查 2000 次数据库/缓存，再做聚合排序，接口响应起码几秒钟，用户早卸载了。
纯推模式（Push / 写扩散）：
逻辑：也就是这哥们答的方案。发视频时，主动推送到所有粉丝的 Inbox。
死穴： 大 V 延迟。 对于千万级粉丝的大 V，发一条动态的成本是天价（写放大），导致资源耗尽。
结论：纯拉模式死于“高关注用户（海王）”，纯推模式死于“大 V 用户（顶流）”。必须搞混合架构！
二、 核心架构：3 种主流解法（从青铜到王者）
解法 1：全量推模式（适合微信朋友圈）—— 青铜段位
如果面试官问的是“微信朋友圈”，那你答“推模式”是满分。
为什么？
因为微信主打“强关系、小圈子”。微信限制了好友上限（比如 5000 人）。 即使你加满了好友，发一条朋友圈，最多也就是写 5000 次 Redis，这对于后台来说毫无压力**。
架构：
写：写入自己的 Outbox + 异步推送给所有好友的 Inbox。
读：直接读自己的 Inbox（Redis ZSet），性能 O(1)。
Fox 点评：业务场景决定架构。微信的“封闭性”决定了推模式是体验最好的。
解法 2：推拉结合（Hybrid 模式）—— 黄金段位
如果面试官问的是“微博/抖音”这种“开放式、有大 V”的平台，必须上混合模式。
核心逻辑： 普通人用“推”，大 V 用“拉”。
流程推演：
判断身份：用户发布视频时，系统判断其粉丝量。
普通用户（粉丝 < 50W）： 走推模式。直接把 Feed ID 写入所有粉丝的 Inbox。
大 V（粉丝 > 50W）： 走拉模式。只写入自己的 Outbox，不推送。
读取逻辑：粉丝请求 Feed 流时，系统执行“混合查询”：
第一步：读取粉丝自己的 Redis Inbox（这里面有普通好友的动态）。
第二步：读取粉丝关注的“大 V 列表”，并发去拉取这些大 V 的 Outbox。
第三步：将 Inbox 数据 + 大 V Outbox 数据，在内存中按时间戳归并排序（Merge Sort）。
第四步：返回给前端。
Fox 点评：这是业界标准解法。既保证了普通用户的实时性，又解决了大 V 发博的写放大问题。
解法 3：存储分层 + 粉丝分层（生产级架构）—— 王者段位
真实的亿级流量系统（如抖音），光靠简单的推拉结合还不够，必须考虑存储成本和极致性能。
1. 存储分层（解决 Redis 贵的问题）：Redis 内存太贵了，存不下全量 Feed 流。
接入层：API 网关 + 流量路由。
缓存层（Redis Cluster）：只存热点 Feed（最近 7 天）和活跃用户的 Inbox。
持久层（HBase / ByteKV）：存储全量 Feed 数据和冷数据。Redis 没命中时，再去查持久层。
2. 粉丝分层（解决“拉”性能问题）：针对大 V，不能对所有粉丝都“拉”，也不能对所有粉丝都“不推”。
铁粉（高频互动）：走推模式。即使是大 V，也给这部分核心粉丝推 Inbox，保证体验。
普通粉/僵尸粉：走拉模式。
大 V 聚合池：对于拉模式，粉丝不是去遍历 100 个大 V 的 Outbox，而是去查询一个“大 V 聚合索引池”（由后台异步聚合热点大 V 内容），一次 I/O 拿到所有大 V 动态。
3. 推荐流融合：关注流不再纯按时间排序，而是融合推荐算法。
双列召回：关注流召回 + 推荐流召回。
统一 Rank：根据互动率、视频质量进行加权重排，最后输出给用户。
三、 最后的“防杠”指南（扫清死角）
设计完架构，面试官会追问这 3 个实战死角，答不上来也是挂：
Q1：Feed 流的分页怎么做？用 limit offset 吗？
答：“绝对不能用 limit offset（深分页问题）。
标准做法：使用 Max_ID（瀑布流） 方式。
前端传给后端：last_feed_id（上一页最后一条的 ID）。
后端查询：Select ... WHERE id < last_feed_id ORDER BY id DESC LIMIT 10。 Redis ZSet 中使用 ZREVRANGEBYSCORE 实现。”
Q2：混合模式下，关注了大 V 多了，拉取还是很慢怎么办？
答：“用‘大 V 聚合池’优化。 系统后台会维护一个‘热点大 V 内容池’（或者用 ES 索引）。 粉丝刷新时，不是去遍历 2000 个大 V 的 Outbox，而是直接读这个聚合池。相当于把‘多次读’变成了‘一次读’，极大降低了 I/O 开销。”
Q3：用户删除了视频，怎么同步给粉丝？
答：“采用‘读时修复’策略。 写扩散模式下，回撤成本太高。我们只在元数据层把状态改为 deleted。 粉丝读取 Inbox 拿到 ID 后，会去查元数据详情（此时通常走 Cache），发现状态是 deleted，则在读取端直接过滤掉。后台再起异步任务慢慢清理无效的 Inbox 数据。”
四、 面试标准答案模板（建议背诵）
下次被问到“Feed 流架构”或“推拉模式”，直接按这个套路输出：
“对于 Feed 流架构，必须根据业务场景和粉丝量级来定：
业务定性：微信朋友圈（双向小圈子）走全量推模式；微博/抖音（单向大 V）走推拉结合。
核心架构：
普通用户：推模式（写 Inbox）。
大 V 用户：拉模式（写 Outbox）+ 粉丝分层策略（铁粉推，路人拉）。
存储优化：考虑到成本，我采用冷热分离。热数据存 Redis，全量历史数据存 HBase/ByteKV。
性能兜底：引入大 V 聚合池优化拉取性能，并配合Max_ID瀑布流分页，确保亿级流量下的丝滑体验。”
https://mp.weixin.qq.com/s/zhAb84ufJty-QlqqGweGdg
