写扩散比读扩散更适合高活跃社交动态流，因其将不可控的读峰值转为可异步削峰、分片预热、失败重试的写压力，避免读扩散中N次查询+内存合并导致的超时与性能雪崩。
为什么 Fan-out 写扩散比读扩散更适合高活跃社交动态流
直接结论：对日活百万级、人均关注 200+ 的动态流场景，write-heavy fan-out（写扩散）通常比 read-heavy fan-out（读扩散）更可控。不是因为写更快，而是读请求的峰值不可预测、延迟敏感，而写可以异步削峰、分片预热、失败重试。
常见错误现象是初期用读扩散（查用户关注列表 → 拉取所有关注者的最新动态 → 合并排序），上线后发现 find({userId: {$in: [...]}}) 在 userId 上无复合索引，或聚合阶段 $lookup 耗时飙升，首页加载动辄 2s+。
- 读扩散要求每次请求都做「N 次查询 + 内存合并」，N 是关注数，中位数超 150 就极易触发 MongoDB 的
maxTimeMS超时或连接池打满 - 写扩散把压力转移到发帖/转发时刻，可用消息队列（如 Kafka）缓冲，配合
bulkWrite批量插入用户时间线 - MongoDB 的
change stream天然适配写扩散失败后的补偿：监听timeline_collection插入失败事件，触发重推
如何设计 timeline 集合结构以支撑写扩散 + 分页查询
关键不是“存什么”，而是“按什么查”。动态流最频繁操作是 GET /feed?max_id=12345，必须避免 skip() 和全集合扫描。
推荐结构：timeline 集合字段为 {_id: ObjectId, userId: "u1001", postId: "p999", createdAt: ISODate, score: Number}，其中 score 是归一化热度值（如 timestamp * 1000 + likeCount），用于替代时间戳排序。
- 强制建立复合索引：
db.timeline.createIndex({userId: 1, score: -1}, {background: true})—— 这是分页性能的生死线 - 禁止用
createdAt单独排序：毫秒级并发写入会导致大量score相同，引发排序不一致和分页跳行 - 分页必须用
score+_id双条件游标：find({userId: "u1001", score: {$lt: 1523456789012}}).sort({score: -1, _id: -1}).limit(20) - 写扩散时，每个
postId对应最多 N 条timeline文档（N = 关注者数），但可通过 TTL 索引自动清理：db.timeline.createIndex({createdAt: 1}, {expireAfterSeconds: 2592000})（30 天）
写扩散失败怎么保证最终一致性？别依赖事务
MongoDB 4.0+ 的多文档事务在跨分片场景下性能差、限制多（如不能含 $text 查询），社交动态流恰恰是典型的跨分片写（用户 A 和其粉丝可能在不同 shard）。真实可行的是基于幂等 + 补偿的最终一致。
核心策略：每条写扩散任务带唯一 fanoutId（如 "post_p999_to_u1001"），插入前先 updateOne({fanoutId: "xxx"}, {...}, {upsert: true})。
- 失败重试必须带重试次数限制（如 ≤ 3 次），否则雪崩；重试间隔用指数退避：
100ms → 300ms → 900ms - 补偿逻辑不放在应用层轮询，而用
change stream监听timeline集合的insert事件，缺失则触发补推 - 用户侧加一层「兜底读扩散」：当某用户 timeline 返回空或明显过旧时，降级调用一次
read-fanout（仅限该用户，且加熔断），避免全站雪崩
什么时候该切回读扩散？看这 3 个信号
写扩散不是银弹。以下情况出现任意一条，就要重新评估模型：
- 用户平均关注数
-
timeline集合写入 QPS 持续 > 5k，同时磁盘 IO wait > 30%，说明批量写已触达单节点吞吐瓶颈（尤其使用 HDD 或低配云盘） - 业务要求「实时可见」，比如内部办公动态，且允许用户主动下拉刷新，此时读扩散 + Redis 缓存最新 50 条，反而更简单可靠
真正难的不是选模型，而是监控两个指标：写扩散的「失败率」和「平均延迟」，以及读扩散的「95 分位聚合耗时」。没埋点就等于闭眼开车。
