直接回答：拉模式（读扩散）：发件人只写自己的发件箱，读者刷新时临时聚合所有关注对象的新内容——写入 O(1)，读取 O（关注数），适合读少写多。推模式（写扩散）：发帖时把帖子 ID 投递到每个粉丝的收件箱（timeline 表），读者一次读收件箱即可——读极快，但大 V 发帖要投递千万级收件箱，写爆炸。工业界标准是混合：普通用户走推，大 V 走拉，读取时合并收件箱与大 V 拉取结果。
展开解析：推模式的工程细节：投递异步化（MQ 扇出任务分片执行）；收件箱只存 ID 加排序分，翻页用游标（WHERE id < cursor）别用 offset；收件箱容量截断（最新 800 条）控制存储。拉模式的优化：大 V 列表加关注时间剪枝，按最近活跃粉丝做在线推/离线拉（僵尸粉不投递，首次上线再拉）——这是微博类系统的经典分级。混合的难点在去重与排序归并：同一帖子可能既被投递又被拉取，按 ID 去重后按时间归并。辅助能力：内容本身与索引分离存储、热度榜走独立计算链路、隐私（仅粉丝可见）在投递时过滤而非读取时过滤（避免拉空页）。规模判断：百万 DAU 内单库收件箱能扛，再往上收件箱按用户分库分表。
追问方向：收件箱分页为什么用游标不用 offset？发帖删除在推模式下如何处理？实时性要求（IM 级）下推模式的延迟构成？
（约 470 字）