GitHub重構Git底層儲存架構，單一儲存庫壓測每秒可接收7,200次推送

GitHub公布新一代Git儲存架構Rubicon，因應大量AI代理同時操作單一程式碼儲存庫的需求。新Git儲存架構經官方內部測試，可支援5,000個AI代理同時作業，每秒處理7,200次程式碼推送（Push），讀取仍維持低延遲。新架構目前僅提供有限私人預覽。

GitHub先前已多次面臨基礎設施負載問題，該公司在6月發布的5月可用性報告指出，AI輔助及代理式開發是平臺流量快速成長的主要因素之一。8月GitHub因流量創新高、關鍵基礎設施未能及時擴充，發生近8小時服務中斷，波及Actions、API和Copilot。GitHub隨後公布，每月程式碼提交量已從4月的14億次增至29億次。

GitHub表示，目前最繁忙的儲存庫在短時間尖峰時，每秒最多只有數十次寫入。隨著更多開發工作轉由全天候運作的AI代理處理，GitHub預期未來一年內，原本短暫的寫入尖峰可能變成持續性負載。每次程式碼推送還會觸發持續整合、部署及其他代理讀取，增加整體請求量，GitHub以一個高流量儲存庫為例，其每日平均請求量從3月的4,400萬次增至5月的1.81億次，約成長4倍。

由於要因應AI代理帶來的持續性讀寫負載，GitHub開發Rubicon架構，將資料儲存、讀寫運算與參照更新分開處理。

GitHub採用既有的請求路由與負載平衡服務Spokes，將來自Git用戶端、API及網頁的讀寫請求，分配給負責處理儲存庫操作的虛擬副本（Virtual Replica），虛擬副本只保留可重建的快取，Git物件以封裝檔案（Packfile）形式存放在Azure Blob Storage，分支等參照資訊與封裝檔案清單，則由GitHub自行開發的參照管理服務Ref-CAS負責。即使某個虛擬副本故障，其餘副本仍可繼續處理請求，替代節點也能依需求重建快取。

Ref-CAS透過比較並交換（Compare-and-Swap）機制管理參照更新，每筆交易只鎖定相關的參照，確認參照未被其他操作修改，並經多數日誌副本確認後才生效。因此，不同AI代理更新各自分支時可以並行處理，不必等待整個儲存庫依序寫入，虛擬副本先上傳Pack，再提交參照交易，避免參照指向尚未保存的資料。

GitHub也把Pack合併整理及垃圾回收交給獨立節點，避免維護作業占用讀寫資源。過去資料維護主要由處理請求的副本執行，新架構則可獨立擴充維護節點，GitHub內部測試顯示，即使寫入量增加，讀寫延遲仍維持平穩。