GitHub 公布新 Git 存储架构 Rubicon：让数千个 AI 代理同时向同一仓库推送

发生了什么事

GitHub 在官方工程博客中表示，上周在 GitHub Universe 上宣布了新的 Git 存储架构。GitHub 称，这套架构每秒可处理数千次写入，读取能力则可按需扩展。仓库是存放项目代码与修改记录的地方；推送（push）是把本地的代码变更上传到 GitHub。GitHub 说，内部测试显示新架构可支持 5,000 个代理同时处理一个仓库，每秒推送 7,200 次，读取延迟也保持稳定偏低。以上数字均为 GitHub 自行公布的测试结果。

GitHub 解释了改造的原因。目前 GitHub.com 最繁忙的仓库每秒最多只有数十次写入，而且通常是短时间的爆发。随着代理并行且全天候工作，GitHub 预计一年内这种爆发会变成持续的高写入量。每次推送还会引发更多读取，例如自动测试和部署系统会拉取新的提交。因此 GitHub 把目标设定为比现在至少高两个数量级（约 100 倍以上）的规模。

新架构如何运作

GitHub 表示，设计的核心观察是：Git 对象（文件内容、提交记录等数据）一旦写入就不会改变，并以内容命名，所以多个写入者可以同时存储，不必相互协调。真正需要协调的只有引用的更新；引用就是“某个分支当前指向哪个提交”这类指针。由于只有引用需要协调，存储数据、处理请求与维护仓库这三件事可以各自独立扩展。

• 对象：GitHub 表示，packs（Git 把许多对象打包在一起的文件）与辅助读取的加速数据，都存放在云对象存储服务 Azure Blob Storage。
• 引用：引用与 pack 清单存放在名为 Ref-CAS 的复制日志服务。Ref-CAS 是 Reference Compare-and-Swap 的缩写，意思是只有当引用仍是写入者预期的值时才更新。每次更新要等多数副本记录后才生效。
• 虚拟副本：可随时替换的计算资源，负责处理读取与写入。它的本地磁盘只是可重建的缓存，仓库变忙时就增加副本。
• 压缩节点：这里的“压缩”（compaction）是指合并文件，而不是删减内容。压缩节点在后台直接对存储服务运行，把许多小 pack 合并成较少、较大的 pack，所有对象都会保留，也不占用处理请求的副本。

对普通读者与开发者的实际影响

GitHub 表示，对开发者而言 Git 仍是 Git：推送、拉取（fetch，下载最新变更）与创建分支的方式都相同，保护机制也保持。GitHub 的目标是让所有仓库，从个人小项目到最繁忙的大型仓库，都运行在同一套架构上，不需要特殊处理。

在推出时间上，GitHub 说这套架构目前只开放有限的私有预览，预计明年初更广泛推出，因此多数用户短期内不会直接感受到变化。GitHub 也列出了后续计划，包括只读取需要的数据、部分副本、全局副本、原子提交 API（一次提交多个文件的变更，要么全部成功、要么整体回退）与事件流等，这些目前都还只是计划。

常见问题

查看同分类最新消息

• 科技新闻