GitHub单仓库每秒7200次push，评论区在问谁来解决冲突

GitHub上周在Universe大会上发布了新的Git存储架构。这周官方博客给出了内部测试数据：5000个agent同时在一个仓库上工作，每秒7200次push，读延迟保持稳定。

先说清楚背景。过去一年agent改变了GitHub上仓库的使用方式。目前最繁忙的仓库每秒也就几十次写入，而且集中在短时突发。但agent是24小时并行跑的，突发会变成持续负载。GitHub的说法是，头部仓库的流量在几个月里翻了4倍，并且还在指数增长。按这个趋势，只规划下一个增量没意义，他们直接把目标定在两个数量级以上的提升。

技术上的关键观察很简单：Git对象不可变，按内容命名。两个写入者同时存同一个对象，不需要协商。一次push里真正需要排序的只有引用更新，也就是分支指向哪个提交，数据量通常只有几十个字节。

这个观察是整个新架构的起点。

架构叫Project Rubicon。名字取自凯撒跨越卢比孔河，原文说的是 agentic development 让行业过了那条不归路。

数据面分三层。Spokes仍然负责路由和负载均衡，做分片、隔离和租户公平性。虚拟副本是一群无状态计算节点，本地磁盘只当缓存，节点挂了就换一个，缓存重建。持久层分两块：Git对象存在Azure Blob Storage，引用和pack manifest存在一个叫Ref-CAS的复制日志服务里。

写路径：虚拟副本索引传入的pack，上传到Blob Storage，然后向Ref-CAS提交一个事务，更新manifest和引用。后台的压缩节点之后会把pack合并，保持读取效率。

读路径：虚拟副本先问Ref-CAS当前引用版本。版本没变就直接返回，不拉任何引用数据。落后了才拿到最新引用和需要下载的pack列表，从Blob Storage拉进缓存再服务。

这套设计里最值得看的是Ref-CAS的诞生过程。GitHub试了两个基于Blob Storage的方案，都没走到最后。

方案一，所有引用更新写进一个blob的write-ahead log。每次更新都是对同一个blob的条件写入。正确性没问题，读也便宜。但同一时刻只能有一个条件写入在飞，就算把批次合并，吞吐也就几百次每秒。

方案二，按引用hash分片到多个blob。不同分片的写入不再互相等待，上限提高了。但读要检查所有分片，延迟由最慢的那个决定。读的数量比写多几个数量级，这个交换不划算。

两个方案都被写进了博客。推特用户NotaDEV在回复里说，试了两个blob方案然后扔掉了，我尊重他们把失败写下来。

最终的Ref-CAS是一个专门做引用更新的复制日志服务。每个引用更新是一个通过quorum提交的CAS事务，只锁涉及的引用。agent大多推自己的分支，不怎么冲突，可以并行提交。每个commit拿到一个log sequence number，仓库的版本就是这个号。读的时候拿版本号去比对，没变就返回空。

Ref-CAS只存指针，不碰对象数据。pack先上传到Blob Storage，引用只指向已经持久化的对象。顺序保证正确性。

压缩的问题紧随其后。每个push会产生一个新pack，pack越多查询越慢。旧架构里压缩跑在服务流量的副本上，新架构把压缩拆到独立节点，通过lease认领分片，直接对Blob Storage操作，结果通过Ref-CAS通知虚拟副本。压缩和读写各自独立扩展。官方给出的效果是，写入上升时延迟曲线保持平坦。

到这里都是存储层面的故事。翻一下推特回复，会发现另一件事。

5000个agent挤进一个仓库，评论区的关注点几乎全在同一个方向。有人问，如果两个agent碰同一个文件，谁来解决？有人说，7200次push每秒，merge conflict现在是一种天气事件。有人直接讲，ref update还是last-writer-wins，所以会有rebase风暴，两个agent把同一个ticket做两遍，我的车队在Git上面用原子认领和短lease来处理。

最后这条来自推特用户John Rood。他点到了存储架构没有解决、也不打算解决的问题：Git的引用更新本身是last-writer-wins。两个agent推同一个分支，后到的覆盖先到的。存储层可以把写入做到每秒几千次，但它不会告诉你另一个agent已经改过同一个函数。

GitHub博客里也提到了下一步的方向：不需要clone的工作流、原子提交API、事件流、轻量clone、更快的历史遍历。这些都在Git和GitHub层面降低agent的工作成本。但agent之间的协调，也就是谁在改哪个文件、谁该等谁、冲突了怎么合并，目前还是每个团队自己在上面搭的东西。

存储架构当然重要。5000个并发agent、7200次push每秒，这个量级的基础设施本身就是一个门槛。没有它，上面的协调问题轮不到讨论。

但一个更实际的问题已经浮出来了：当agent的数量不再受存储限制，限制它的是什么？

目前这个架构还在limited private preview，明年早期扩大范围。届时会有更多人拿它跑真实的agent队伍，然后发现存储确实不再是瓶颈。

下一个瓶颈是什么，评论区已经给出了答案。

参考来源：

• GitHub官方博客：Inside GitHub's new Git storage architecture（Karthik Raman & Brian Celenza）
• 推特讨论：@github 相关回复