百亿级 Feed 流架构设计：微博/朋友圈的“推拉模式” (Push vs Pull) 到底该怎么选？

🌊 前言：发一条朋友圈，后台发生了什么？

你以为发朋友圈只是往数据库插了一条记录？
错！

对于微信朋友圈这种熟人社交（好友一般几百人），系统可能需要把你的动态“推送”给这几百人的信箱。
但对于微博这种媒体社交，如果**周杰伦（粉丝 5000 万）**发了一条状态，系统难道要瞬间插入 5000 万条数据到粉丝的信箱里吗？数据库会瞬间熔断，整个机房都会冒烟。

这就是 Feed 流系统设计最核心的难题：写扩散 (Write Fan-out) vs 读扩散 (Read Fan-out)。

今天，我们从架构视角，深挖百亿级 Feed 流的**“推拉之战”**。

🥊 模式一：推模式 (Push / 写扩散)

原理：
也叫**“写扩散”。每个用户都有一个收件箱 (Inbox)**。
当用户 A 发布一条动态时，系统会遍历 A 的所有粉丝，把这条动态的 ID 插入到每一个粉丝的收件箱里。

场景：
微信朋友圈。因为你的好友上限只有 5000，且大部分人好友不多，推模式的延迟极低。

架构图解：

• 优点：
  • 读操作极快：粉丝刷新 Feed 流时，不需要复杂的查询，直接读自己的 Inbox (Redis ZSet) 即可。
  • 高可用：某个用户的 Inbox 挂了，不影响其他人。
• 缺点：
  • 存储成本高：一份数据被复制了 N 份。
  • “大V”灾难：如果粉丝量达到千万级，发一条动态需要写千万次 Redis，会有巨大的同步延迟（粉丝可能几分钟后才刷到）。

🧲 模式二：拉模式 (Pull / 读扩散)

原理：
也叫**“读扩散”。每个用户有一个发件箱 (Outbox)**。
用户 A 发布动态，只写自己的 Outbox。
当粉丝 B 刷新首页时，系统去查询 B 关注的所有人（A, C, D…）的 Outbox，把最新的动态拉取回来，在内存中进行排序聚合。

场景：
早期的微博，或者关注人数很少的系统。

架构图解：

• 优点：
  • 写操作极快：只写一条数据。
  • 节省空间：数据不冗余。
• 缺点：
  • 读操作极慢：如果你关注了 2000 个人，刷新一下首页需要查 2000 次数据库/缓存，然后排序。这对系统的QPS是毁灭性的打击。

⚖️ 终极方案：推拉结合 (Hybrid) —— 微博/抖音的选择

既然推模式怕大V，拉模式怕高并发读，那为什么不混合使用呢？

核心策略：
将用户划分为**“大V”和“普通用户”，将粉丝划分为“活跃用户”和“僵尸粉”**。

1. 针对“大V”（在线推，离线拉）

当周杰伦（大V）发布动态时：

• 在线粉丝（Push）：只将动态 ID 推送给当前在线或最近活跃的粉丝的 Inbox。这样数据量可控。
• 离线/所有粉丝（Pull）：将动态写入周杰伦的 Outbox。当不活跃的粉丝上线时，再去拉取。

2. 针对“普通用户”（全量推）

当你的邻居（只有 200 粉丝）发布动态时：

• 直接使用Push 模式，写扩散到这 200 个人的 Inbox。成本忽略不计。

Redis ZSet 实战代码片段：

// 推模式示例：给活跃粉丝推送 Feed IDpublicvoidpushFeedToActiveFollowers(LongfeedId,LongauthorId){// 1. 获取活跃粉丝列表 (BitMap 或 缓存)List<Long>activeFans=followerService.getActiveFollowers(authorId);// 2. 管道批量写入 Redis ZSetredisTemplate.executePipelined((RedisCallback<Object>)connection->{for(LongfanId:activeFans){Stringkey="inbox:"+fanId;// Score 使用时间戳，方便排序connection.zAdd(key.getBytes(),System.currentTimeMillis(),String.valueOf(feedId).getBytes());// 限制长度，只保留最近 1000 条connection.zRemRangeByRank(key.getBytes(),0,-(1000+1));}returnnull;});}

💾 存储选型：海量数据存哪里？

光有逻辑不行，数据存哪里也是关键。

1. Feed ID 列表（关系数据）：
   • Redis ZSet：性能最好，适合存 Timeline 的 ID 列表。
   • Tair / RocksDB：如果内存太贵，可以使用磁盘 KV 存储。
2. Feed 内容（正文数据）：
   • HBase / Cassandra：适合海量写入、通过 RowKey (FeedID) 查询的场景。
   • MySQL：分库分表也可以，但成本较高。

📝 总结

没有最好的架构，只有最适合业务场景的架构。

• 朋友圈：好友少，直接用Push。
• 微博/Twitter：粉丝关系极度倾斜，必须用Push + Pull 结合。
• 企业级系统：如果是简单的站内信，Pull模式足够了。

下次面试官问你“怎么设计 Feed 流”，先把推拉结合甩在他脸上，然后细聊在线状态判断和冷热数据分离。