「如何設計一個分散式雲端硬碟同步系統（Dropbox / Google Drive / OneDrive）？」是系統設計面試中最能考察候選人對「大檔案傳輸優化」、「儲存與中繼資料分離」以及「分散式並發衝突解決」理解深度的經典高階題目。
當使用者在本地修改了一個 1GB 檔案中的其中 1 行代碼時，系統如果每次都重新上傳這 1GB 的檔案，將會對使用者頻寬與伺服器造成毀滅性的浪費。
Dropbox 之所以能顛覆整個雲端儲存產業，核心正是其精妙的 區塊級差異同步（Block-Level Delta Sync） 與 中繼資料分離架構。
本文將依照頂級科技公司系統面試標準，完整拆解 Dropbox 的核心架構拓撲。
1. 核心需求與設計約束
- 功能性需求：
- 跨多設備（PC、Mac、手機）自動即時同步檔案與資料夾。
- 支援大檔案上傳（最高支援數十 GB），且修改時僅傳輸差異部分。
- 支援離線編輯，上線後自動合併同步。
- 支援檔案歷史版本回溯（File Versioning）。
- 非功能性需求：
- 極致資料持久性（11 個 9）：使用者檔案絕不能丟失。
- 極致頻寬節省：最小化網路傳輸量與手機電量消耗。
2. Dropbox 全鏈路架構拓撲：中繼資料與區塊儲存分離
3. 區塊級差異同步（Delta Sync）與滾動雜湊
3.1 為什麼需要 4MB 分塊（Chunking）？
- 當一個 100MB 檔案被切分為 25 個 4MB 的獨立 Chunk 時：
- 使用者只修改了檔案結尾的 2KB 資料。
- 客戶端本地比對 SHA-256，發現前 24 個 Chunk 完全未變，僅有第 25 個 Chunk 的 Hash 發生改變。
- 網路傳輸量瞬間從 100MB 驟降至 4MB（節省 96% 頻寬）！
3.2 滾動雜湊（Rolling Hash / Rabin Fingerprint）解決插入移位
若使用者在檔案開頭插入了 1 個 Byte：
- 若採用固定 4MB 切分，所有後續 Chunk 的邊界都會向後平移 1 Byte，導致所有 25 個 Chunk 的 Hash 全部失效。
- 滾動雜湊解法：在字節流中滑動視窗，尋找特定的雜湊特徵碼作為「動態邊界切分點（Content-Defined Chunking）」，確保插入資料只會影響局部的 1~2 個 Chunk，其餘 Chunk 保持不變。
3.3 全域重複資料刪除（Cross-User Deduplication）
如果 10,000 個不同使用者都在網盤中保存了同一部熱門開源影片（例如 Ubuntu 安裝映像檔）：
- 伺服器發現該檔案所有 Chunk 的 SHA-256 在 S3 區塊儲存庫中已經存在。
- 伺服器完全無需使用者再次上傳該區塊（秒傳功能！），只需在 Metadata 資料庫中將該 Chunk ID 關聯至該使用者的檔案目錄下，節省了海量的雲端儲存成本。
4. 併發衝突解決機制（Conflict Resolution）
當使用者在筆記型電腦離線修改了 doc.txt，同時在手機上也編輯了 doc.txt，兩台設備重新聯網同步時會發生衝突：
- 不採用強制覆蓋（Last-Write-Wins 会丟失數據）：採用「保留衝突副本（Conflicted Copy）」策略，讓使用者自主決定如何合併內容。
5. 系統設計面試核心要點
- 架構分離清晰：嚴格劃分「Block Storage（二進位大檔案）」與「Metadata DB（目錄樹與版本號）」。
- 傳輸極致優化：深入解釋 4MB Chunking、SHA-256 尋址、滾動雜湊與斷點續傳。
- 即時同步閉環：透過 WebSocket / SSE 推播事件通知其他客戶端發起拉取（Pull-on-Notification）。
- 衝突防護嚴密：基於版本號樂觀鎖與衝突副本檔案機制保證資料絕對安全。