Dropbox 首席工程师助手

要解决的问题

同步引擎每天要处理 700M+ 台设备上的并发编辑、离线修改和网络分区，必须收敛到一致状态。用户改了 200MB PDF 的其中一页，客户端不应重传整份文件；存储层要扛下 EB 级数据（1+ trillion objects）同时控制成本；分布式系统中任意一次故障都不能丢数据、不能产生孤儿文件，也不能破坏因果序。

技能如何工作

核心能力：

• Delta 同步管线：4MB 固定分块 → SHA-256 哈希识别 → 服务端去重 → 仅上传变更块 → 原子提交 + Pub/Sub 通知。Manifest-first 让服务端直接告诉客户端需要哪些块，单项去重即可节省约 25% 磁盘占用。
• Magic Pocket 存储决策：热数据 2× 副本、冷数据纠删码（1.4× 开销），单机 Diskotech 1PB，修复 SLA < 48 小时，以「慢即是稳」换取长期正确性。
• 冲突处理策略：普通文件 Last-Writer-Wins + 冲突副本；Office 文档走应用层合并；Paper 用 OT/CRDT 实时协作；代码文件先尝试 Git 风格合并。
• 测试哲学：CanopyCheck 属性测试，每天数百万随机种子，给定种子可 100% 复现；Trinity 三条不变量守护数据安全。

关键步骤：

1. 决策优先级：数据持久性 > 可用性 > 性能 > 成本 > 迭代速度，正确性永远先于优化。
2. Memo-first 流程：1 页问题陈述 → 6 页设计文档（会前静默阅读 30 分钟，禁 PPT）→ 灰度发布 + 回滚预案 → 上线复盘对比预测指标。
3. 按场景选型：核心系统用 Rust（内存安全、穷尽测试），服务用 Go，工具用 Python。

适用边界与注意点

• 本技能聚焦 Dropbox 式自建基础设施语境（如 AWS 迁出案例），不等于通用云存储咨询；4MB 分块、副本系数等具体数字需按实际负载重新验证。
• OT/CRDT 协作、纠删码参数属于工程选型讨论，不替代生产环境的容量规划与压测。
• 资料未展开 AWS 迁移的实施细节，相关决策只能给出原则性参考。
• 公司数据截至 FY2025，战略已转向 Dash（AI 助手）与 B2B，员工数反映 2024 裁员后状态，引用时需注意时效。