GitHub ra mắt kiến trúc lưu trữ Git mới cho kỷ nguyên tác nhân AI

Tại sự kiện GitHub Universe, GitHub đã công bố kiến trúc lưu trữ Git thế hệ mới, có thể xử lý hàng nghìn lượt ghi mỗi giây với khả năng đọc mở rộng theo nhu cầu. Qua kiểm thử nội bộ, hệ thống chứng minh khả năng hỗ trợ 5.000 tác nhân AI cùng làm việc trên một kho mã, gửi tới 7.200 lượt push mỗi giây, trong khi vẫn phục vụ lưu lượng đọc với độ trễ thấp ổn định.

Bối cảnh: tác nhân AI thay đổi lưu lượng kho mã

Trong năm qua, các tác nhân AI đã thay đổi diện mạo của những kho mã bận rộn nhất trên GitHub. Những kho này hiện nhận tối đa vài chục lượt ghi mỗi giây, thường theo từng đợt ngắn. Khi công việc chuyển dần sang các tác nhân chạy song song liên tục, GitHub dự đoán các đợt bùng nổ này sẽ trở thành tốc độ duy trì trong vòng một năm tới. Mỗi lượt push lại kéo theo nhiều lượt đọc hơn từ CI, hệ thống triển khai và các tác nhân khác, tạo hiệu ứng khuếch đại lớn.

Một kho mã trên GitHub đã tăng lưu lượng khoảng 4 lần từ tháng 3 đến tháng 5 và tiếp tục tăng theo quỹ đạo hàm mũ. Thay vì chỉ tính cho bước tăng kế tiếp, GitHub đặt mục tiêu quy mô lớn hơn ít nhất hai bậc độ lớn.

Yêu cầu thiết kế cho một kho mã đơn lẻ

• Chấp nhận hàng nghìn lượt ghi mỗi giây
• Hỗ trợ nhiều nút ghi, do việc đánh chỉ mục gói dữ liệu và kiểm tra kết nối đối tượng là phần tốn CPU nhất của một lượt ghi, chi phí tăng theo kích thước gói
• Giảm thiểu độ trễ commit vì tác nhân phải chờ mỗi lượt push trước khi sang bước tiếp theo
• Ghi nhận thay đổi theo thứ tự cho từng tham chiếu, có khả năng tuyến tính hóa nhanh giữa các tham chiếu
• Giữ chi phí đọc thấp khi không có thay đổi, trường hợp phổ biến do tỷ lệ đọc/ghi
• Cho phép từng thành phần mở rộng độc lập

Dự án Rubicon

Tháng 5/2026, ngay sau đợt di chuyển ban đầu lên Azure, GitHub bắt đầu thiết kế đáp ứng các yêu cầu trên. Sau nhiều phương án thử nghiệm, họ chọn thiết kế tối đa hóa thông lượng trong khi vẫn giữ các đảm bảo về tính đúng đắn, độ bền, tính sẵn sàng và độ trễ, đặt tên là Rubicon — ám chỉ điểm không thể quay đầu mà ngành đã vượt qua với phát triển bằng tác nhân AI.

Phần lớn hệ thống giữ nguyên: yêu cầu từ Git client, API và giao diện web vẫn đến Spokes, thành phần đảm nhận định tuyến, cân bằng tải và duy trì phân vùng, cô lập, công bằng giữa các tenant. Phần data plane bên dưới Spokes là mới hoàn toàn.

Spokes định tuyến mỗi yêu cầu tới một nhóm nhỏ bản sao ảo (virtual replica) được gán cho kho mã. Đây là đội máy tính dùng một lần, phục vụ đọc, ghi hoặc cả hai, với đĩa cục bộ chỉ là bộ nhớ đệm có thể tái tạo bất cứ lúc nào. Khi kho mã bận, hệ thống thêm bản sao ảo; một đội nút nén chạy nền trực tiếp trên Blob Storage và Ref-CAS để gộp các gói dữ liệu và dọn đối tượng không thể truy cập.

Trạng thái bền vững nằm ở hai nơi

• Đối tượng Git (gói dữ liệu và dữ liệu tăng tốc đọc) lưu trong Azure Blob Storage
• Tham chiếu và danh sách gói dữ liệu của kho mã lưu trong dịch vụ log sao chép riêng gọi là Ref-CAS

Với một lượt ghi, bản sao ảo đánh chỉ mục gói dữ liệu đến, tải lên Blob Storage, rồi commit một giao dịch vào Ref-CAS để ghi gói vào manifest và cập nhật tham chiếu. Với một lượt đọc, bản sao ảo kiểm tra phiên bản tham chiếu với Ref-CAS, kéo các gói cần thiết vào bộ nhớ đệm rồi phục vụ từ đó.

Tối thiểu hóa phối hợp: cập nhật tham chiếu ở thông lượng cao

Blob Storage rất phù hợp với dữ liệu ghi một lần rồi bất biến như gói dữ liệu, chỉ mục, dữ liệu tăng tốc đọc và checkpoint. Nhưng tham chiếu thì ngược lại: một lượng trạng thái nhỏ mà nhiều lượt ghi tranh nhau cập nhật cùng lúc.

GitHub thử hai cách. Cách đầu là write-ahead log cho toàn bộ tham chiếu, đánh chỉ mục bằng một blob duy nhất — đúng đắn và đọc rẻ, nhưng chỉ một lượt ghi có điều kiện được bay cùng lúc, thực tế chỉ đạt thông lượng ghi vài trăm lượt mỗi giây. Cách hai chia tham chiếu thành nhiều blob phân đoạn, nâng trần ghi nhưng buộc mỗi lượt đọc phải kiểm tra mọi phân đoạn, đánh đổi độ trễ đọc — vốn nhiều hơn ghi hàng bậc độ lớn.

Vì vậy họ xây Ref-CAS, dịch vụ log sao chép dành riêng cho tham chiếu. Mỗi cập nhật tham chiếu là một compare-and-swap được commit bởi một nhóm đồng thuận. Giao dịch chỉ khóa các tham chiếu nó chạm tới, kiểm tra giá trị mong đợi và hiển thị khi đa số bản sao của log đã ghi nhận. Do tác nhân chủ yếu push lên nhánh riêng, hầu hết cập nhật không tranh chấp và sao chép song song. Mỗi commit nhận một số thứ tự log (LSN), và phiên bản của kho mã là LSN của commit mới nhất.

Nguồn: GitHub Blog