GitHub tách dữ liệu Git khỏi cập nhật nhánh để xử lý nhiều lượt push

Trong bài kỹ thuật ngày 5/11/2026, GitHub giải thích cách họ thay đổi hạ tầng lưu kho Git để nhiều người hoặc tác nhân tự động có thể đẩy thay đổi cùng lúc. Phần lớn dữ liệu của một lượt đẩy có thể được lưu song song. Chỗ cần điều phối chặt là việc quyết định nhánh sẽ trỏ tới bản ghi lịch sử nào sau khi ghi xong.

Hai việc diễn ra trong một lượt đẩy mã

Giả sử hai lập trình viên làm cùng một kho mã nhưng trên hai nhánh khác nhau. Khi mỗi người chạy thao tác đẩy, máy chủ nhận những đối tượng Git còn thiếu. Đó có thể là nội dung tệp, cấu trúc thư mục và bản ghi lịch sử gọi là commit. Git nhận diện đối tượng bằng dấu vết tính từ nội dung. Sau khi tạo, đối tượng đó không được sửa ngay tại chỗ: nội dung khác tạo ra một đối tượng khác.

Nhánh lại là tên mà người dùng có thể tiếp tục cập nhật. Nó chứa một tham chiếu tới commit hiện là đầu nhánh. Để nhìn thấy thay đổi vừa được đẩy, người dùng cần cả đối tượng mới và tham chiếu dẫn đến nó. Tải dữ liệu lên mà không cập nhật tham chiếu chưa tương đương với một lượt đẩy thành công.

Hai lượt ghi vào hai nhánh độc lập không nhất thiết phải chờ nhau chỉ vì chúng dùng chung kho mã. Nhưng hai lượt cùng muốn đổi một đầu nhánh cần được kiểm tra theo trạng thái hiện tại. Nếu cả hai đều dựa vào đầu nhánh cũ và máy chủ chấp nhận vô điều kiện, một lần cập nhật có thể ghi đè kết quả của lần kia. Vì thế, giảm hàng đợi cho các nhánh độc lập vẫn phải giữ cơ chế xử lý xung đột ở từng nhánh.

Vì sao thứ tự lưu quan trọng?

GitHub mô tả việc ghi gói đối tượng lên Azure Blob Storage trước khi xác nhận giao dịch đổi tham chiếu. Đây là dịch vụ lưu trữ các khối dữ liệu, tách khỏi máy xử lý yêu cầu Git. Thứ tự này bảo đảm một tham chiếu vừa công bố không trỏ tới dữ liệu chỉ tồn tại tạm trong bộ nhớ của máy nhận yêu cầu. Nếu máy đó gặp sự cố sau khi giao dịch được xác nhận, các đối tượng đã ở nơi lưu bền vững.

GitHub gọi dịch vụ quản lý trạng thái tham chiếu là Ref-CAS. Có thể hiểu phần so sánh và cập nhật như yêu cầu: chỉ đổi đầu nhánh nếu giá trị hiện tại vẫn là giá trị dự kiến. Điều kiện ấy hữu ích khi nhiều thao tác đến đồng thời. Dịch vụ này không cần giữ toàn bộ mã nguồn để làm nhiệm vụ của mình; nó xử lý trạng thái tham chiếu và thông tin liên quan tới những gói đã lưu.

Tách phần nặng khỏi quyết định cần nhất quán giúp nhà vận hành phân bổ tài nguyên theo từng loại tải. Nhiều máy có thể tiếp nhận và kiểm tra gói dữ liệu, trong khi việc quyết định thứ tự vẫn áp dụng ở phạm vi cần thiết. Điều đó không làm biến mất độ trễ mạng hoặc biến một nhánh duy nhất thành nơi có thể ghi không giới hạn.

Một lượt ghi có thể kéo theo nhiều lượt đọc

Ngay sau khi có commit mới, hệ thống kiểm thử có thể tải mã, công cụ triển khai có thể đọc lại phiên bản và người khác cập nhật bản làm việc. Với nhiều tác vụ chạy đồng thời, chi phí phục vụ lượt đọc có thể tăng nhanh hơn số người đang trực tiếp đẩy mã. Tách tài nguyên đọc khỏi tài nguyên xử lý ghi cho phép tăng năng lực cho bên đang chịu tải thay vì nhân thêm cả cụm giống hệt nhau.

Còn một chi phí ít thấy: mỗi lượt đẩy có thể thêm một gói đối tượng. Khi số gói tăng, việc tìm đối tượng qua nhiều gói có thể tốn công hơn. GitHub mô tả chuyển việc gom các gói sang các máy nền chuyên trách. Công việc ấy có thể được phân chia theo phần dữ liệu, thay vì để từng máy đang phục vụ người dùng tự lặp lại việc gom. Hạ tầng vẫn phải thông báo cho bên đọc về trạng thái mới để không bỏ sót dữ liệu.

Mô hình này làm giảm cạnh tranh tài nguyên giữa tác vụ bảo trì và yêu cầu trực tiếp. Đổi lại, hệ thống phải theo dõi độ trễ của việc gom gói, xử lý máy nền ngừng hoạt động và quan sát những kho mã tạo dữ liệu nhanh hơn khả năng dọn dẹp. Đưa công việc ra nền chỉ có ích nếu công việc ấy vẫn theo kịp tốc độ phát sinh.

Đọc đúng con số thử tải của GitHub

GitHub báo cáo thử nội bộ với 5.000 tác nhân đồng thời và 7.200 lượt đẩy mỗi giây trên một kho. Đây là kết quả do chính bên vận hành công bố trong thiết lập thử nghiệm của họ. Nó không cho biết một lượt đẩy từ Việt Nam sẽ mất bao lâu, hoặc một kho có gói lớn và quy tắc kiểm tra riêng sẽ đạt thông lượng tương tự.

Với nhóm có nhiều tác vụ tự động, cách phân nhánh vẫn đáng quan tâm. Nếu mọi tác vụ cùng cố cập nhật một nhánh, xung đột ở đầu nhánh vẫn tồn tại dù hệ thống bên dưới có thêm năng lực. Tách công việc vào các nhánh rồi hợp nhất theo quy trình kiểm tra giúp phân biệt hai vấn đề: máy chủ có tiếp nhận được nhiều dữ liệu hay không, và thay đổi nào thực sự nên đi vào nhánh chung.

Đội vận hành cũng có thể nhìn ra điểm nghẽn kế tiếp bằng cách đo thời gian từ lúc đẩy xong đến lúc kiểm thử bắt đầu và hoàn tất. Hạ tầng Git xử lý nhanh hơn vẫn có thể để lại hàng đợi ở máy chạy kiểm thử hoặc khâu duyệt. Kiến trúc GitHub giải quyết một phần của đường đi đó; cách tổ chức công việc của nhóm quyết định phần cải thiện có đến được người dùng cuối hay không.

Nguồn: GitHub, kiến trúc lưu trữ Git, ngày 5/11/2026; GitHub, giai đoạn chuyển đổi hạ tầng; Pro Git, tham chiếu Git.

Sơ đồ minh họa luồng dữ liệu Git cơ bản, không phải sơ đồ kiến trúc GitHub. Lbhtw, CC BY-SA 3.0; dùng nguyên bản.