信息流系统设计

方案 A：拉模式（Pull / 读扩散）

当用户张三发了一条微博，系统只把微博写入张三自己的发件箱（Outbox）。当李四（张三的粉丝）打开微博时，系统再去查询李四关注的所有人，并从这些人的发件箱里拉取最新微博，最后在内存中做按时间排序的合并。

优点：写操作极轻量（写一次就行）。存储成本低，没有冗余数据。

缺点：读操作极重（读扩散）。如果李四关注了 1000 个人，每次刷新就要读 1000 个人的发件箱，还要做内存排序，高并发下响应极慢。

方案 B：推模式（Push / 写扩散）

当用户张三发了一条微博，系统不仅写入张三的发件箱，还会立刻把这条微博的 ID（或内容）复制分发到张三所有粉丝的收件箱（Inbox）。李四刷新微博时，直接读取自己的收件箱即可。

优点：读操作极快（只需读一个收件箱）。

缺点：写操作极重（写扩散）。如果张三有 1000 万粉丝，发一条微博就需要触发 1000 万次写操作

方案 C：混合模式

在真实的信息流业务中，大 V（明星、大号）拥有千万级甚至亿级粉丝，如果使用纯推模式，大 V 发一条微博会瞬间造成系统写雪崩。

因此，可以采用基于用户分类的混合模式：

普通用户发微博：采用推模式。粉丝量少，直接推送到所有粉丝的收件箱（Inbox）。

大 V 发微博：采用拉模式。只写入自己的发件箱（Outbox），不进行广播推送。

用户刷新信息流（Feed）时：

首先，读取自己的收件箱（Inbox），这里面包含普通好友推过来的微博。

其次，去查询自己关注列表中是否有大 V，如果有，实时拉取这些大 V 发件箱里的最新微博。

最后，在内存中将两部分数据通过时间戳进行 Merge Sort（归并排序），呈现给用户。