Cursor用S3预写日志将Git存储扩展至每秒300次以上

Cursor开发的Continuity架构将S3上的预写日志（WAL）作为Git存储的最终依据，不再依赖多个副本相互协调来维持一致性。测试中，系统最多使用100个副本时读取能力仍可线性扩展；在S3 Express One Zone上，每秒Push请求超过300次，既面向高CI负载的大型仓库，也适合编码智能体产生的大量小仓库。

Git托管通常依赖本地Git仓库和packfile。GitHub的Spokes架构通过多个NVMe副本提供服务，并以三阶段提交同步引用，但副本规模扩大后，协调成本也会随之上升。Continuity则先把Push数据写入S3，再将引用变更记录进WAL；只有所需数据完成持久化，系统才确认Push成功。系统还会批量处理操作，以降低S3 PUT延迟对吞吐的影响。

本地NVMe在Continuity中只是温缓存，不是权威副本。系统用会合哈希选择优先节点，并通过S3的原子比较并交换允许任意服务器接收Push；若节点没有本地仓库，也能依据WAL重新生成。WAL更新通过UDP Gossip传播，带条件的S3读取用于校验副本状态，平均耗时低于10毫秒。即使Gossip消息丢失，S3仍能保证数据正确性。这种设计也带有数据库特征，Push一致性、Force Push事务和时间点恢复都需要进一步处理。

Liatrio首席技术官、前AWS员工Casey Lee认为，S3中的WAL才是事实来源，NVMe仅承担缓存角色，但他同时指出，公开的性能数据尚未经过独立验证。

Continuity允许单体仓库为CI扩展到数百个副本，长期无活动的仓库则可在需要时再生成本地副本。Git压缩只由主副本执行，其他副本从S3下载生成的packfile，从而减少重复CPU开销，但会增加带宽消耗。基于Cursor的everysphere单体仓库测试显示，S3 Standard每秒最多处理120次Push，S3 Express One Zone超过300次；吞吐继续提高后，Git压缩成为瓶颈。测试中的Push满足线性一致性，确认前数据已写入外部存储，Clone也保持一致。

整体而言，该架构把一致性保障从副本协调转移到持久化对象存储，让本地仓库独立收敛到S3记录的状态，并依靠校验和异步传播维护副本。代价是需要承担额外带宽，以及对象存储读写和校验带来的系统复杂度。