想像一下，你正在咖啡廳用筆電整理今天的待辦事項，突然WiFi斷線了。但你發現應用程式依然流暢運作，新增的任務立即出現在清單上。當你拿出手機查看時，驚訝地發現剛才離線時建立的所有任務都已經同步過來了。更神奇的是，你的同事正在即時協作編輯共享的專案任務清單，每個人的修改都能無縫整合。
這看似簡單的使用體驗背後，隱藏著分散式系統設計中最複雜的挑戰之一：如何在離線環境下維持資料一致性？當多個裝置同時修改同一份資料時，該如何解決衝突？這就是今天我們要探討的核心問題。從技術角度來看，待辦事項系統已經從簡單的CRUD應用演化成複雜的分散式協作平台。整個產業朝向離線優先（offline-first）架構發展。
現代使用者的工作模式已經徹底改變。我們在手機上快速記錄靈感，在平板上規劃專案，在電腦上執行任務。這種跨裝置的工作流程對待辦系統提出了前所未有的挑戰。
系統必須能夠在各種網路環境下正常運作：從高速 WiFi 到不穩定的行動網路，甚至完全離線的飛行模式。更重要的是，使用者期望所有的操作都能即時響應，不會因為網路問題而卡頓或遺失資料。
技術挑戰 1：離線資料持久化
瀏覽器儲存 API 的限制與選擇困境。IndexedDB 提供大容量但 API 複雜，localStorage 簡單但容量有限，如何設計混合儲存策略？
技術挑戰 2：衝突檢測與解決
當多個裝置離線修改同一資料時，如何檢測衝突？採用自動合併還是讓使用者介入？不同類型的資料需要不同的解決策略。
技術挑戰 3：同步效率優化
全量同步 vs 增量同步的取捨，如何處理大量累積的離線操作？網路不穩定時的重試策略與效能影響。
| 維度 | 雲端優先架構 | 離線優先架構 | 混合架構 |
|---|---|---|---|
| 核心特點 | 伺服器為資料權威來源 | 本地資料庫為主要來源 | 智慧切換主從關係 |
| 優勢 | 實作簡單、資料一致性強 | 極佳離線體驗、零延遲響應 | 平衡離線與協作需求 |
| 劣勢 | 離線功能受限、網路依賴高 | 同步複雜度高、衝突處理困難 | 架構複雜、狀態管理挑戰 |
| 適用場景 | 企業內部系統、強網路環境 | 個人應用、弱網路地區 | 通用型產品、跨國團隊 |
| 複雜度 | 低 | 高 | 極高 |
| 成本 | 伺服器成本高 | 客戶端開發成本高 | 整體成本最高 |
架構重點：
系統架構圖：
為什麼這樣設計：
架構演進重點：
關鍵設計變更：
儲存層升級
同步協議優化
企業級架構特點：
架構設計考量：
高可用性設計
擴展性規劃
營運效率
| 技術選項 | 優勢 | 劣勢 | 適用場景 |
|---|---|---|---|
| IndexedDB | 大容量(50MB+)、非同步API、支援索引 | API複雜、瀏覽器差異 | 主要資料儲存 |
| localStorage | API簡單、同步存取 | 容量限制(5-10MB)、阻塞主線程 | 設定與快取 |
| OPFS | 檔案系統存取、大容量 | API較新、相容性問題 | 未來選項 |
| 演算法 | 複雜度 | 衝突處理 | 網路需求 | 代表應用 |
|---|---|---|---|---|
| CRDT | 高 | 自動 | 可離線 | Notion、Figma |
| OT | 中 | 需協調 | 需連線 | Google Docs |
| Event Sourcing | 中 | 可重播 | 可離線 | 金融系統 |
| LWW(Last-Write-Wins) | 低 | 覆蓋 | 可離線 | 簡單系統 |
系統架構的演進必須考慮向後相容性。
從 localStorage 遷移到 IndexedDB 時，需要實作資料遷移邏輯。
從簡單同步升級到 CRDT 時，需要保持 API 介面的穩定性。
每個階段的技術債務都需要在下一階段償還，因此初期的架構決策會深遠影響系統的可維護性。
過早優化陷阱
同步頻率誤區
Notion的區塊架構演進 參考：Notion技術部落格
初期（2016-2018）
成長期（2018-2021）
近期狀態（2021-2025）
當使用者離線操作時，所有變更都被記錄在本地佇列中：
interface OfflineQueue {
operations: Operation[];
enqueue(op: Operation): void {
// 添加操作到佇列
this.operations.push({
...op,
id: generateUUID(),
timestamp: Date.now(),
status: 'pending'
});
// 持久化到 IndexedDB
this.persistQueue();
// 嘗試同步
this.attemptSync();
}
async attemptSync(): Promise<void> {
if (!navigator.onLine) return;
const pending = this.operations.filter(
op => op.status === 'pending'
);
for (const op of pending) {
try {
await this.syncOperation(op);
op.status = 'synced';
} catch (error) {
op.retryCount = (op.retryCount || 0) + 1;
// 實施指數退避策略
op.nextRetry = Date.now() +
Math.pow(2, op.retryCount) * 1000;
}
}
}
}
使用 LWW-Register（Last-Write-Wins Register）處理任務標題衝突：
class LWWRegister<T> {
private value: T
private timestamp: number
private nodeId: string
merge(other: LWWRegister<T>): void {
// 時間戳較大者獲勝
if (other.timestamp > this.timestamp) {
this.value = other.value
this.timestamp = other.timestamp
this.nodeId = other.nodeId
} else if (other.timestamp === this.timestamp && other.nodeId > this.nodeId) {
// 時間戳相同時，節點 ID 較大者獲勝（確定性）
this.value = other.value
this.nodeId = other.nodeId
}
}
set(value: T): void {
this.value = value
this.timestamp = Date.now()
// 使用混合時間戳避免時鐘偏差問題
this.timestamp = Math.max(this.timestamp, lastKnownTimestamp + 1)
}
}
技術指標：
業務指標：
自動化監控
版本相容性管理
資料完整性檢查
針對今日探討的待辦事項系統離線同步設計，建議可從以下關鍵字或概念深化研究與實踐，以擴展技術視野與解決方案能力：
CRDT 深入研究：透過進一步學習 Automerge、Yjs 等框架的原理與實作，能加強對分散式資料結構的理解與應用。
混合邏輯時鐘（Hybrid Logical Clocks）：這部分涉及解決分散式系統時間同步問題的關鍵技術，適合深入掌握以提升系統一致性。
Event Sourcing 與 CQRS 模式：探索事件驅動架構的本質及其最佳實踐，幫助設計更具擴展性和可維護性的同步系統。
WebAssembly 與本地資料庫：關注 SQLite WASM 等新興技術的發展，保持技術與時俱進，尋找創新解決方案。
可根據自身興趣，針對上述關鍵字搜尋最新技術文章、專業書籍或參加線上課程，逐步累積專業知識和實踐經驗。
明天我們將探討「圖片上傳分享系統」的設計。從圖片壓縮、CDN 分發到智慧裁切，這個看似簡單的功能背後隱藏著許多效能優化的挑戰。我們將深入分析如何處理大檔案上傳、實作漸進式圖片載入，以及設計可擴展的圖片處理管線。準備好迎接視覺內容時代的架構挑戰了嗎？
iThome鐵人賽
看影片追技術