Cursor Continuity 以 S3 WAL 重構 Git 儲存，測試每秒 Push 逾 300 次

AI 前線報導稱，Cursor 開發的 Git 儲存架構 Continuity 將 S3 上的預寫日誌（Write-Ahead Log，WAL）作為一致性的最終依據，不再依靠副本間協調維持狀態。合成測試中，系統最多使用 100 個副本時，讀取能力可隨副本數量線性增加；使用 S3 Standard 時每秒最多處理 120 次 Push，換用 S3 Express One Zone 後則超過 300 次。Cursor 表示，測試中的 Push 符合線性一致性要求，資料在回應成功前已持久化至外部儲存，Clone 操作也維持一致性；不過相關性能數據尚未經獨立驗證。 Continuity 會先將 Push 上傳的資料寫入 S3，再把引用更新記錄到 WAL；只有所需資料完成持久化後，系統才確認 Push 成功。系統也會對操作批次處理，以降低 S3 PUT 請求延遲對吞吐量的影響。S3 WAL 是權威資料來源，本地 NVMe 上的 Git 儲存庫只作為溫快取；系統透過 Rendezvous Hashing（會合雜湊）選擇優先處理請求的節點，並使用 S3 的原子比較並交換（Compare-and-Swap）操作，讓任意伺服器都能接受 Push。若本地沒有儲存庫副本，也能依 WAL 重新產生。 WAL 更新會透過 UDP Gossip 在節點間傳播，系統再以條件式 S3 讀取檢查副本狀態；Cursor 稱這類讀取平均耗時低於 10 毫秒。即使 Gossip 訊息遺失，也不會影響資料正確性，因為 S3 始終是事實來源。對於單體儲存庫，Cursor 表示 Continuity 可因應 CI 工作負載擴展到數百個副本；暫時沒有活動的儲存庫則可在需要時才建立本地副本。 Git 壓縮只由主副本執行，其他副本直接從 S3 下載壓縮後產生的 packfile，可減少重複 CPU 開銷，但會增加頻寬消耗。在 Cursor 的 everysphere 單體儲存庫合成測試中，吞吐量進一步提高後，Git 壓縮成為新的性能瓶頸。這種設計把一致性保障從副本層移至持久化物件儲存，降低副本同步協調成本，但需承擔額外頻寬與非同步狀態傳播的代價。相關評論則將 Continuity 比作以資料庫架構設計 Git 儲存，並指出 Push 一致性、Force Push 交易與時間點復原等問題仍值得關注。