檔案儲存與跨裝置同步服務。難點在於強一致性、快速同步與節省頻寬三者的組合——重點放在檔案元資料管理與檔案同步兩條流程。
📋 Requirements
- 功能：上傳/下載檔案、跨多裝置同步、版本歷史、分享、變更通知。
- 規模：1,000 萬 DAU、5,000 萬註冊、每人 10 GB、單檔 ≤ 10 GB；讀寫比 1。上傳尖峰約 480 QPS，總配置空間約 500 PB。
- 非功能：可靠（不可遺失資料）、快速同步、省頻寬、可擴展、高可用；儲存中檔案須加密、走 HTTPS。
🧠 Core Ideas
TIP
核心是「把檔案切成區塊存進物件儲存 + 元資料庫追蹤 檔案/區塊/版本 + 只同步變更區塊 + 通知服務推變更」。
檔案內容存在雲端（S3），元資料庫只存元資料。單機起步後逐步解耦：加負載平衡器、Web/API 伺服器可水平增減、元資料庫做複寫與 sharding（見一致性雜湊概念），檔案改存物件儲存並跨區域複寫。
⚖️ Reference Design
區塊化與 Block 伺服器
- 檔案切成區塊，每塊有唯一雜湊值、當成獨立物件存進雲端儲存；重建時依序接合。以 Dropbox 為參考，區塊上限 4MB。
- Block 伺服器負責上傳繁重工作：切塊 → 壓縮（依檔案類型選演算法，如 gzip/bzip2）→ 加密 → 上傳。
- Delta sync：檔案被改時只傳被修改的區塊，而非整個檔案，藉此省頻寬。
元資料庫與強一致性
- Schema 含 User、Device、Namespace、File、File_version（唯讀以保版本完整）、Block 等表。
- 系統要求強一致性：不同用戶端不可同時看到同一檔案不同內容。
- 快取預設最終一致，須讓快取副本與主節點一致、且寫入 DB 時讓快取失效。選關聯式 DB，因原生支援 ACID。
上傳/下載與通知
- 上傳（見同步 vs 非同步）：新增元資料（狀態 pending）與上傳到雲端儲存兩請求平行；上傳完成回 callback 後改狀態為 uploaded，並通知相關用戶端。
- 下載：由他處變更觸發；用戶端先拉元資料、再向 block 伺服器下載區塊重建檔案。
- 通知服務是 pub/sub；選 long polling（單向、通知頻率不高），而非 WebSocket。離線用戶端的變更先存起來，上線再拉取（離線備份佇列）。
同步衝突與節省儲存
- 衝突解決：先被處理的版本獲勝，後者收到衝突；系統呈現本地與伺服器兩份，讓使用者合併或覆蓋。
- 省空間三招：區塊去重（雜湊相同即同一塊）、智慧備份策略（設版本數上限、只留有價值的近期版本）、把冷資料移到冷儲存（如 S3 Glacier）。
🔑 Takeaways
- 設計重心是元資料管理與檔案同步兩條流程，通知服務用 long polling 串起變更。
- 區塊化 + delta sync + 壓縮省頻寬；去重 + 版本上限 + 冷儲存省空間。
- 強一致性靠關聯式 DB 的 ACID，並在寫入時讓快取失效。
- 集中在 block 伺服器做切塊/壓縮/加密（而非用戶端），避免跨平台重工與用戶端被操控。
No notes yet — jot your takeaways or Q&A here.