系统设计 Lab
文件同步其实是两套系统套了一件外衣：一个话痨般的 metadata service，和一个体量庞大的 block store，两者沿着完全不同的轴扩展。
调一调活跃用户、每人文件数、文件大小、编辑速率、每人设备数、chunk 大小和 region 数。设计会从一个盒子，长成一个把变更 push 给每台设备的 notification service、带 dedup 的 content-addressed chunking、一个分片的 metadata 数据库，以及为共享与协作做的多 region block replication。
分步讲解
一步一步把它想清楚
要点
常规演进场景
从左到右点击，就是预设的演示路径。每张卡片都会改变 workload 输入。
推荐形态
当前架构路径
设备
客户端设备 监视本地文件夹，上传变更的 chunk，并应用远端的变更
Sync API
Sync API 处理 chunk 的上传与下载，并提交文件变更
Notification 文件一变，就告诉该用户的每台其他设备，好让它们去拉取
Metadata
Metadata svc 存放 file tree、版本和权限；那个话痨般的 source of truth
Chunk index 把内容 hash 映射到存好的 block，让相同的 chunk 只存一份
Block store
Block store 一个持久的 content-addressed 存储，装着每一个唯一的文件 chunk
Replicas 把 block 跨 region 复制，让上传和下载都就近完成
Async
Indexer 把变更事件 fan-out 给设备，并在 hot path 之外构建搜索和共享索引
瓶颈
Metadata QPS
Notification fan-out
Block 存储
Dedup 省下的字节
冲突 / 版本压力
为什么会变
决策权衡
有出处支撑的规则
这些是模型背后那些经得起时间考验的 system design 论断。而 slider 的具体阈值，则被刻意标注为教学用的假设。
Dropbox 把 metadata service 和 block storage 分了开
Dropbox 用 Magic Pocket 作为专门的 exabyte 级 block store，而文件 metadata 则放在另一个、按不同维度扩展的服务里。
Dropbox Engineering文件被切成 content-addressed block
Content-addressable storage 用内容的 hash 给每个 block 命名，于是相同的 block 只存一份——这正是 block-level dedup 的基础。
Content-addressable storageContent-defined chunking 让跨文件去重成为可能
Low-Bandwidth File System 证明了：对变长的内容 chunk 做 hash，能让同步系统只传输、只存储真正变化过的那些 chunk。
LBFS (SOSP 2001)Long-polling 让客户端不必忙轮询也能及时得知变更
一条挂着不放的请求（long-poll 或 server-sent stream）让服务端在变更发生的当下就通知设备，而不是让设备按定时器轮询。
MDN Web Docs教学用假设
- Metadata QPS 是由编辑数、加上每次变更要通知的设备数估算出来的，不是实测流量。
- 单节点的 metadata 读取和存储预算是偏保守的教学数字，不是厂商的真实上限。
- Dedup 省下的量用的是总字节的一个固定比例；真实节省高度取决于内容实际被共享了多少。