Git仓库托管越做越难：Spokes到Continuity的十年血泪！
内容提要
Git仓库托管面临分布式存储难题，GitHub的Spokes系统通过三阶段提交保证同步，但扩展性受限且运维复杂。Cursor的Continuity改用S3预写日志作为事实来源，本地仓库仅作缓存，支持无状态扩展和高效压缩，但未经长期生产验证，其可靠性仍是未知数。
延伸解读
Spokes的扩展性瓶颈
Spokes通过三阶段提交保证副本同步，但这也限制了其水平扩展能力。副本越多，推送延迟越高，因为每一步都受最慢服务器拖累。GitHub最初每个仓库仅三个副本，但到2026年，面对CI流量和智能体创建的海量小仓库，三个副本已不够用，而增加副本又会降低性能。这种设计“下限太高、上限太低”，难以适应现代需求。
Continuity的运维优势
Continuity将事实来源从本地磁盘转移到S3中的预写日志，使系统无状态化。这消除了Spokes中必须维护路由表、跟踪每个仓库位置的运维负担。即使节点不健康或映射出错，也能从WAL恢复仓库，无需人工干预。这种设计大幅降低了运维复杂度，让系统更易于扩展和管理。
Continuity的可靠性未知
尽管Continuity的设计在理论上更优雅，但尚未经过长期生产验证。文章指出，合成压力测试无法模拟真实环境中的网络分区、磁盘故障、GC停顿等问题。S3的延迟和可用性在极端负载下的表现、CAS重试的竞争条件、UDP广播的扩展性都是未知数。Spokes有十三年生产经验，而Continuity的长期可靠性仍是问号。
Q&A
GitHub的Spokes系统是如何保证多个副本之间同步一致的？
Spokes通过三阶段提交来保证同步一致。每次推送先将packfile扇出到所有副本，然后对引用事务执行三阶段提交，确保所有副本完全同步，读取操作可以安全地路由到任意副本。
Spokes系统的主要缺陷是什么？
Spokes有两个主要缺陷：一是水平扩展能力受限，三阶段提交的延迟受最慢副本拖累，副本越多推送吞吐量越低；二是运维极其复杂，需要维护路由表、计算校验和、持续监控仓库健康，且每个仓库必须保持三个副本，无法缩减。
Continuity系统与Spokes在数据存储上有什么本质区别？
Continuity将S3中的预写日志（WAL）作为事实来源，本地仓库仅作为热缓存；而Spokes将磁盘上的原生Git仓库作为事实来源。Continuity因此实现了无状态扩展，无需维护路由表，副本可以随意增减。
Continuity如何实现无状态扩展？
Continuity将事实来源放在S3的WAL中，本地仓库只是缓存。系统没有路由表，任何节点都可以通过WAL恢复仓库。使用rendezvous hashing映射仓库到节点，但即使映射出错或节点不健康，也可以在下一个节点恢复。所有更新通过S3的原子比较并交换同步，无需共识选举。
Continuity如何处理副本同步和读取一致性？
Continuity使用UDP广播通知副本有新数据，副本收到广播后，在读取时通过S3条件GET验证是否最新。如果返回304则直接处理，返回200则先追数据再处理。S3条件GET平均不到10毫秒，保证了读取的一致性。
Continuity在压缩（repack）方面有什么优化？
Continuity只让主节点执行压缩，压缩结果同时应用到本地仓库和WAL，所有副本通过WAL跟随压缩事件，无需各自重新打包，而是从S3下载已压缩的pack，用带宽换CPU，避免了Spokes中多副本同时压缩导致的故障转移风险。
Continuity的可靠性存在哪些未知数？
Continuity尚未经过长期生产验证，其可靠性未知。具体包括：S3在极端负载下的延迟和可用性表现、CAS重试在真正大规模竞争条件下的退化程度、UDP广播在复杂网络拓扑中的扩展性，以及合成测试无法覆盖的真实环境问题（如网络分区、磁盘慢盘、GC停顿等）。
