Cursor公開Origin底層Git架構，以S3預寫日誌因應AI代理大量儲存庫
<div class="field field-name-field-news-column-category field-type-taxonomy-term-reference field-label-hidden"><div class="field-items"><div class="field-item even"><a href="/tags/%E6%96%B0%E8%81%9E">新聞</a></div></div></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>Cursor<strong><a href="https://cursor.com/blog/git-at-any-scale">公開</a></strong>程式碼託管服務Origin的底層Git儲存系統Continuity，採用S3相容物件儲存中的預寫日誌（WAL）保存每次推送的資料，本機Git儲存庫則成為可隨時重建的快取。新架構主要因應兩種負載，一是企業持續擴大的大型單一儲存庫，另一種則是AI代理大量建立但很少使用的小型儲存庫。</p> <p>Git託管服務通常會把同一個儲存庫複製到多臺伺服器，以提高可用性並分擔讀取流量。不過副本越多，開發者推送程式碼時需要同步的伺服器也越多，可能拖慢寫入速度，而小型儲存庫要是固定保存多份副本，又會占用不必要的運算與儲存資源。Cursor指出，AI代理開始大量操作Git後，使得這兩種擴充問題更加明顯。</p> <p>Continuity因此將S3上的預寫日誌作為資料的最終依據，當開發者推送程式碼後，系統先將資料完整寫入S3，再回覆操作成功。本機仍使用標準Git儲存庫和高速NVMe儲存裝置處理日常操作，但伺服器上的副本不再是資料的最終依據，即使副本遺失，也能從S3重新建立，不必固定追蹤每個儲存庫存放在哪幾臺伺服器。</p> <p>副本數也能跟著使用量調整，大型單一儲存庫可增加更多副本分擔讀取工作，AI代理建立而且很少使用的小型儲存庫則可只保留一份，閒置一段時間後甚至能從伺服器磁碟移除，需要時再從S3重建。</p> <p>Cursor公布的合成壓力測試顯示，Continuity增加至100個副本時，唯讀Git操作仍能隨副本數增加而擴充，未觀察到程式碼推送速度下降。使用S3 Standard時，每秒最多可處理120次推送，而改用延遲較低的S3 Express One Zone後則超過300次，相關數字均為Cursor自行測試結果。</p> <p>GitHub近期也面臨程式碼託管容量快速成長的壓力，8月17日因美國中部資料中心關鍵元件無法隨流量擴充，<strong><a href="https://github.blog/news-insights/company-news/the-august-17-outage-and-the-work-ahead/">服務中斷7小時47分鐘</a></strong>。官方表示，今年4月至今每月程式碼提交數已從14億增至29億，目前Azure約承擔GitHub 58%的平臺負載及一半Git操作，後續還將先從大型單一儲存庫開始，導入可隨讀取端數量增加而擴充處理能力的新架構。</p> </div></div></div>
