一句话结论
Cursor 发布的 Continuity 架构通过 S3 预写日志确立数据权威源，在合成测试中实现每秒 300 多次 Push，显著提升 Git 托管扩展性。
关键要点
- 在合成测试中，使用 S3 Express One Zone 时，系统每秒可处理超过 300 次 Push 请求。
- 最多使用 100 个副本时，读取能力能够随副本数量线性增长，无需副本间同步协调。
- 使用 S3 Standard 时，系统每秒最多处理 120 次 Push，换用 S3 Express One Zone 后性能超过 300 次。
- 本地 NVMe 仓库仅作为温缓存，数据事实来源为 S3 上的预写日志，支持从日志重新生成仓库。
- 单体仓库可为 CI 工作负载扩展到数百个副本，Git 压缩仅由主副本执行，其他副本直接下载压缩后的 packfile。
背景与事实
Cursor 开发的 Continuity 架构旨在解决大规模 Git 托管的扩展性问题。传统架构如 GitHub 的 Spokes 通过维护多个 NVMe 副本并使用三阶段提交来保证一致性，但副本数量增加会导致协调开销显著上升。Continuity 采用不同思路，将 S3 上的预写日志作为持久化存储的事实来源。当用户执行 Push 操作时，数据先写入 S3，引用更新记录到日志中，只有数据完成持久化后才确认请求成功。系统对操作进行批处理以降低 S3 请求延迟对吞吐量的影响，本地 NVMe 仅承担温缓存功能，并非权威副本。
在实现细节上，系统通过会合哈希选择优先处理请求的节点，并利用 S3 原子比较并交换操作让任意服务器都能接受 Push 请求。预写日志更新通过 UDP Gossip 协议在节点间传播，系统使用带条件的 S3 读取校验副本状态，平均耗时不到 10 毫秒。即使消息丢失也不影响数据正确性，因为 S3 始终作为事实来源。Cursor 工程师 Vicent Martí 强调，本地仓库副本缺失时可根据日志重新生成。对于暂时没有活动的仓库，系统可延迟生成副本直到需要时再处理。Git 压缩仅由主副本执行，其他副本直接从 S3 下载压缩后的 packfile，虽然增加了带宽消耗，但减少了重复的 CPU 开销。
影响分析
对中文开发者与从业者而言，这一架构分析表明云存储正在重构代码托管系统的扩展模型。将持久化层从本地高速存储转移到对象存储，意味着中小团队在构建内部 Git 服务时，可以更低成本获得高可用性和线性扩展能力，尤其适合 CI 负载繁重的大型仓库或编码智能体创建的大量小型仓库场景。但需注意，当前性能数据来自 Cursor 合成测试，尚未独立验证，实际生产环境需结合网络延迟、S3 版本选择与仓库分布重新评估吞吐与成本。
适用边界
该结论适用于以 S3 兼容对象存储为基础、追求高吞吐 Git 托管的云平台设计场景。不适用于对实时一致性要求极高、无法接受对象存储延迟、或必须依赖本地 NVMe 作为唯一权威副本的边缘计算与离线 Git 服务场景。
孤本观察
编辑判断认为，将 Git 存储一致性锚点从副本协调转移到对象存储日志，标志着代码托管架构向云原生数据层深度融合，未来 Git 平台将更依赖存储基础设施的原子性与可校验性，而非传统分布式同步机制。
常见问题
Cursor Continuity 架构在 S3 Express One Zone 下每秒能处理多少次 Push 请求？
在合成测试中，使用 S3 Express One Zone 时，系统每秒可处理超过 300 次 Push 请求。
Continuity 架构最多支持多少个副本且如何扩展读取能力？
最多使用 100 个副本，读取能力随副本数量线性增长，且无需副本间进行同步协调。
使用 S3 Standard 与 S3 Express One Zone 时 Push 吞吐量有何差异？
使用 S3 Standard 时每秒最多处理 120 次 Push；换用 S3 Express One Zone 后性能超过每秒 300 次。
Continuity 架构中 Git 压缩任务由哪个副本执行？
Git 压缩仅由主副本执行，其他副本直接从 S3 下载压缩后的 packfile，以避免重复 CPU 开销。
该架构适用于对实时一致性要求极高的边缘计算场景吗？
不适用。该架构不适用于对实时一致性要求极高、无法接受对象存储延迟或必须依赖本地 NVMe 作为唯一权威副本的场景。
来源：InfoQ 中文 AI