GitHub 全新 Git 儲存架構解析

GitHub 在 GitHub Universe 上宣布了新的 Git 儲存架構。這套架構能每秒處理數千次寫入，讀取效能也能隨需求擴展。這套新架構是 GitHub 支援數億開發者進行代理程式開發的基礎。內部測試顯示，該架構支援 5,000 個並行代理程式對單一儲存庫操作，並能對單一儲存庫每秒發送 7,200 次推送，同時在提供讀取流量時持續維持低延遲。

GitHub 是在系統持續運行的情況下，在後端建構這套新架構。在系列的第一篇文章中，GitHub 說明了下一代 Git 儲存架構的兩個原則：最小化協調，以及將儲存與運算解耦。GitHub 已將 99.99999% 的儲存庫遷移至 Azure，把寫入法定人數的範圍縮小到個別參考，並建立了由 Azure Blob Storage 支撐的虛擬副本。在新架構中，GitHub 幾乎把所有需要持久化的資料都存放在 Azure Blob Storage，包括推入、壓縮和垃圾回收所寫入的 Packs 和索引。各種讀取加速器（如多 pack 索引、可達性位元影像和某些自訂格式）也存放在 Azure Blob Storage。壓縮和垃圾回收用來恢復或審計工作的記錄，以及壓縮節點用來聲稱工作的租約，同樣存放在這裡。常被重複擷取的快取回應，以及儲存庫參考狀態的檢查點（不包含用於服務請求的權威狀態），也放在 Azure Blob Storage。在這套架構中，大部分資料只會寫入一次，且寫到不同的金鑰，之後不再變更。

GitHub 發現，繁忙儲存庫的參考狀態只是相對少量的狀態，卻有許多寫入同時競爭更新。GitHub 的第一個原型顯示，對參考狀態這種工作負載，物件儲存雖然直覺，在一定規模下也運作良好，但會面臨兩難的取捨。GitHub 的第一種做法，是替儲存庫的所有參考建立寫入前日誌，並以單一 blob 作為索引。這種做法下，每次更新都是對該 blob 的條件寫入。然而，同一時間只能有一個針對該 blob 的條件寫入在進行。即使把寫入期間到達的每次推入都合併進下一次寫入，儲存庫的寫入上限仍是每次往返只能對單一 blob 寫入一次。實際上，這使寫入吞吐量只有每秒幾百次。

Ref-CAS 獨立排序每個參考，而不是整個儲存庫。GitHub 透過新增虛擬副本來擴展讀取和寫入能力，透過新增壓縮節點來擴展維護能力。GitHub 已能穩定呈現延遲曲線不隨寫入量增加而上升的結果。GitHub 的目標是讓每個儲存庫，從單一開發者的副專案到最繁忙的單一儲存庫，都在同一套架構上運行，繁忙的儲存庫也不需要特殊處理。GitHub 認為，單一架構也意味著每項改進都能同時惠及每個儲存庫。

GitHub 目前專注於三個領域：擴展架構以超越今日可預測的需求、讓代理程式在 GitHub 上執行工作時更有效率，以及為代理程式開發演進 Git 本身。GitHub 計劃讓儲存庫只獲取所需內容，也就是從 Blob Storage 取得單一物件，而不是取得包含該物件的整個 pack。GitHub 計劃按類型組織 packs，把提交、樹和 blob 分別放進各自的 packs。GitHub 計劃實作部分副本，讓請求在沒有所有 pack 都位於本機磁碟的情況下也能被服務。GitHub 計劃使用實體化視圖，讓儲存庫資料保持在即用形式，例如預備好的歸檔、預設分支的近即時淺層副本，以及與每個提交一起儲存的代理程式工作階段內容。GitHub 計劃實作全域副本，把副本放在靠近使用它們的工作負載的任何區域。GitHub 計劃讓讀取維持在最新寫入的有界陳舊度內。GitHub 計劃實作縮減至零，讓機隊規模隨實際活躍的儲存庫增長和縮小。GitHub 另有其他規劃中的優化措施，目的是讓壓縮和垃圾回收過程本身的效能更好。