GitHub Git 存储架构 Project Rubicon

概述

GitHub 推出了一种新的 Git 存储架构，内部代号为“Project Rubicon”，旨在支持代理驱动开发（agent-driven development）的激增。该系统旨在处理单个存储库每秒数千次的写入操作，同时保持低延迟的读取性能。通过将存储与计算解耦并最大限度地减少协调需求，GitHub 旨在将存储库容量扩展两个数量级，以适应预期中自主代理活动的增长。

核心架构：解耦与协调

Rubicon 架构摒弃了传统的单体 Git 存储，转向基于两个主要设计原则的分布式模型：最小化协调和存储与计算解耦。

Ref-CAS：管理引用状态

由于 Git 对象是不可变的，因此它们不需要复杂的协调。然而，引用更新（如分支指针）则需要。GitHub 开发了一个名为 Ref-CAS（Reference Compare-and-Swap，引用比较并交换）的专用服务来处理这些更新。与传统的共识组不同，Ref-CAS 不存储或验证实际的对象数据；它只存储指针和日志序列号。这使得系统能够通过仅锁定事务中涉及的特定引用，每秒处理数万次引用更新。

虚拟副本与 Blob 存储

所有持久化的 Git 对象数据都被卸载到 Azure Blob Storage，这提供了高聚合吞吐量。流量通过“Spokes”路由到一组一次性的 虚拟副本（virtual replicas）。这些副本充当缓存层，按需从 Blob Storage 拉取必要的包数据。由于虚拟副本不持有权威状态，它们可以水平扩展或替换，而不会影响存储库的正确性。

后台压缩

为了在写入量增加时保持读取性能，GitHub 将压缩和垃圾回收移至后台进程。专用的压缩节点直接针对 Blob Storage 和 Ref-CAS 进行操作。通过使用租约（leases）来声明对特定存储库分片的拥有权，这些节点可以独立于虚拟副本合并包并删除不可达对象，从而确保副本上的计算资源专注于处理用户请求。

行业背景与社区讨论

这一公告引发了关于此类高吞吐量基础设施必要性的广泛讨论。虽然 GitHub 将其定位为面向 AI 驱动编码未来的前瞻性措施，但一些社区成员质疑了其架构影响。

  • 扩展与速率限制： 批评者认为，支持每秒数千次推送可能会鼓励低效的代理行为。评论者建议，平台可能最终需要强制执行速率限制，或鼓励代理在推送前在本地聚合更改，而不是为海量写入量构建基础设施。
  • 与其他系统的比较： 观察人士指出，这种方法与其他行业努力有相似之处，例如 Cursor 的 "Continuity" 或像 enroute.sh 这样的独立项目，它们也利用对象存储进行 Git 扩展。
  • VCS 替代方案： 一些开发者质疑 Git 是否仍然是高并发代理集群的最佳工具。建议包括转向像 Perforce 这样的系统，它提供独占文件锁定功能——对于管理大规模自动化协作而言，这可能比 Git 的乐观并发模型更合适。

GitHub 表示，该新架构目前处于有限的私有预览阶段，计划于明年年初进行更广泛的推广。该公司强调，这一基础将支持未来的功能，如“无需克隆即可工作”（work without a clone）、原子提交 API，以及对部分克隆和浅克隆的改进支持。

Sources