GitHub提交量年增5倍 重建Git儲存層

GitHub首席軟體工程師Brian Celenza於10月6日在官方工程部落格發文，揭露公司正在重建Git儲存層。原因寫得很直接：AI代理（agent）把寫入流量推向了現有架構的上限。在內部基準測試中，新架構的寫入吞吐量最高提升35倍。

文章列出過去一年的成長數字：

負載最重的單一儲存庫，8月單月就收到約10億次請求。文章這樣描述代理的寫入習慣：

"An agent in a tight loop commits or checkpoints after nearly every action"

（循環執行的代理幾乎每做一個動作就提交或打一次檢查點。）

舊架構卡在寫入瓶頸

GitHub現行的儲存庫儲存系統叫Spokes。每個儲存庫預設在多台檔案伺服器的本機磁碟上各存一份完整副本，共5份。推送更新參照（reference）時，系統採用多數決的三階段提交協議，確保CI、網站與API用戶端看到一致的儲存庫狀態。

在這套設計裡，副本同時負責兩件事：防止資料遺失，以及分攤讀取請求。代價是每份副本都要參與每一次寫入，增加副本能提升讀取能力，寫入反而變慢。在人類開發者主導、讀取遠多於寫入的年代，這個取捨沒什麼問題；但代理把寫入頻率拉高之後，副本數量本身成了寫入的瓶頸。

新架構拆成三個部分

第一部分是把協調壓到最少：只有參照更新需要多方達成共識，物件儲存、驗證、安全掃描都改成平行處理。

第二部分是儲存與運算分離。持久化交給Azure Blob Storage，讀取請求則由一批輕量工作行程處理。文章的說法是：

"Separating the two lets us scale each one independently"

（把兩者分開，就能各自獨立擴充。）

第三部分是把背景維護獨立出來，壓縮與垃圾回收改由獨立的工作行程執行，不再與即時請求搶資源。分支保護、強制審查、稽核日誌與可觀測性等控管機制則全數保留。

粗估一下寫入負載

以一個月30天粗略估算，每月73.8億次提交等於每秒約2850次；每月33.5億次推送等於每秒約1290次，一年前約為每秒270次。若每次推送都要5份副本參與，舊架構每秒要處理的副本寫入大約在6500次上下（這只是粗估，未計入重試與維護作業）。

35倍的吞吐量提升，對應的是年增4.9倍的推送成長速度，帳面上留出了好幾年的餘裕。前提是代理流量的成長曲線不再持續變陡，而這一點GitHub自己也給不出預測。

文章沒交代的部分

新架構目前已遷移多少儲存庫、何時全面切換，文章並未提供時間表；35倍這個基準測試用的是什麼規模的儲存庫、多大的並發量，也沒有說明。至於對使用者可能有哪些影響，例如速率限制是否會調整，文中同樣沒有提及。

今年GitHub發生過幾次較長時間的服務中斷，這篇文章並未回應這些事故，也沒有說明新架構能否避免類似情況。Celenza在結尾預告，系列下一篇會更詳細說明未來架構，以及這次改造的來龍去脈。

參考來源：GitHub官方工程部落格、CocoLoop；GitHub官方數據核實每月提交、推送與Actions執行量的統計口徑。