首页/数据/NoSQL 速查/读扩散与写扩散的取舍
本包目录(322 条)
MongoDB99 条Elasticsearch89 条ClickHouse56 条时序与列式28 条
选型与架构50 条

读扩散与写扩散的取舍

推送(写扩散)在写入时把数据分发到多处,读路径简单但写成本乘以扇出数;拉取(读扩散)在读取时聚合多处数据,写便宜但读延迟与查询成本高。社交时间线、关注流常见混合方案:活跃用户推送、长尾拉取。

NoSQL 速查数据更新于 2026-10-12
写扩散发布时写向所有订阅方收件箱:读快;粉丝多的大 V 写放大明显,不活跃用户占用存储
读扩散读时合并关注列表:写简单;关注多时聚合慢,缓存压力在读侧
混合按活跃度分流:活跃用户预先推送,非活跃用户读时拉取合并

混合时间线的结构示意

混合时间线的结构示意
发布事件 → 判断作者粉丝规模
  ├─ 粉丝少:写给每个粉丝的收件箱(写扩散,如 500 以内)
  └─ 粉丝多:只写作者时间线(读扩散)
读时间线 = 合并(收件箱最新 N 条, 关注的大 V 最新 N 条) → 排序截断
搜索与列式库也常做写扩散:ES 把宽文档预拼好、ClickHouse 物化视图预聚合,本质都是用写入成本换读取成本。

易错点

  • 给数百万粉丝的账号做全量写扩散,发布一次产生海量写入并抬高延迟
  • 纯读扩散在关注数很大时每次都要聚合多路数据,读路径超时后容易恶性循环

数据来源与参考

  • Twitter Engineering Blog: Timelines(概念参考)
  • MongoDB Manual: Materialized views
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌