GitHub公布新Git存储架构：内部测试支持 5000 个并发代理向单仓库写入
GitHub官方博客称，新架构“Rubicon”在内部测试中演示了单仓库每秒 7200 次推送、5000 个并发代理同时工作，读取延迟保持低位。该架构将Git对象存入Azure Blob Storage，并将引用状态交由独立的Ref-CAS服务处理。
AI解读：GitHub在官方博客中介绍了新的Git存储架构“Rubicon”，称内部测试演示了单仓库支持 5000 个并发代理、每秒 7200 次推送，并保持读取低延迟。这些数字来自GitHub的内部测试，不是第三方验证。
架构把Git对象（pack）放在Azure Blob Storage，把引用和pack清单放到自建的复制日志服务Ref-CAS。GitHub表示，只有引用更新需要达成一致，因此存储、请求处理和仓库维护可以独立扩展。
GitHub称，现有线上最繁忙仓库每秒最多接收几十次写入，通常还是短时突发；它为单仓库设定的目标是至少提升两个数量级，以应对代理并行、全天候开发带来的持续写入。
同一架构适用于从个人项目到大型monorepo的所有仓库，不针对繁忙仓库做特殊处理。GitHub称已规划读取单个对象、按对象类型分pack、部分副本、全局副本等后续改进，但未给出上线时间表。
GitHub在官方博客中公布了新的Git存储架构“Rubicon”。GitHub称，内部测试演示了单仓库支持 5000 个并发代理、每秒 7200 次推送，同时以稳定低延迟提供读取流量。
GitHub表示，对开发者而言Git用法不变：推送、拉取和分支操作与之前相同，原有保护机制也保留。
GitHub为代理场景设定的写入目标
GitHub将平台扩展分为两个方向：横向是让更多开发者和代理跨多个仓库工作，纵向是让更多开发者和代理同时操作一个仓库。博客称，新架构的需求主要来自纵向方向。
GitHub称，目前GitHub.com上最繁忙的仓库每秒最多接收几十次写入，通常是短时突发；随着代理并行、全天候运行，它预计这类突发在未来一年内变成持续速率。每次推送还会触发CI、部署系统和其他代理的读取，形成放大效应。
为此，GitHub为单仓库设定的目标是：每秒接受数千次写入、支持多个写入节点、降低提交延迟、按每个引用记录变更顺序、在无变化时保持读取低成本，并让各组件独立扩展。
“Rubicon”的写入与读取路径
新架构名为“Rubicon”。请求仍先到达GitHub的路由与负载均衡层Spokes，由Spokes将请求分发给为该仓库分配的一组虚拟副本。虚拟副本是可替换的计算节点，本地磁盘只作缓存，可随时重建。
写入时，虚拟副本为传入的pack建立索引并上传到Azure Blob Storage，然后向Ref-CAS提交一个事务，把该pack列入清单并更新引用。后台的压缩节点随后合并pack，以控制pack数量。
读取时，虚拟副本先向Ref-CAS核对版本；若版本未变，Ref-CAS不返回引用数据，只需一次比较。若版本落后，则取回当前引用和版本，以及需要下载的pack指针，再从Blob Storage拉取所需数据。
Ref-CAS是专用于引用状态的复制日志服务，每次引用更新是一次经多数副本确认的compare-and-swap，只锁定涉及的引用。GitHub称，该服务只保存指向对象的指针，不保存或校验对象数据；虚拟副本会先把pack上传到Blob Storage，再提交引用事务。
压缩与垃圾回收移到独立节点
GitHub称，旧架构中压缩与提供流量的副本运行在一起，且每个副本都要执行；新架构把压缩放到独立的后台节点，直接针对Blob Storage和Ref-CAS工作，并通过租约让同一分片同时只有一个节点压缩。
压缩节点把新pack收集到段中，段达到数量、大小或时间上限后封存，再合并成更少、更大的pack。发布前会校验新pack与输入包含完全相同的对象，然后更新清单并删除输入pack。GitHub称，这样写入上升时pack数量保持大致平稳，延迟曲线也保持平稳。
垃圾回收同样由专用worker处理计算量大的部分，用于删除已删除分支和force-push留下的不可达对象。博客未给出垃圾回收的独立性能数字。
GitHub的后续计划
GitHub称，目标是让所有仓库——从个人副项目到最繁忙的monorepo——都运行在同一架构上，繁忙仓库无需特殊迁移或处理。
博客列出的架构改进包括：从Blob Storage读取单个对象而非整个pack、按提交/树/ blob类型分pack、部分副本、物化视图、靠近工作负载的全局副本，以及按活跃仓库伸缩的“scale to zero”。代理操作方面，GitHub提到无需完整克隆即可工作的方向。这些均为计划，博客未给出上线时间。