Cursor 发布 Continuity 架构扩展 Git 存储
先了解这件事
2026年10月13日，InfoQ中文报道Cursor发布了名为Continuity的Git存储架构。该架构利用基于S3的预写日志（WAL）作为数据最终依据，不再依赖副本间同步协调来保证一致性。在合成测试中，使用S3 Express One Zone时，读取能力随副本数量线性增长，Push请求处理量超过每秒300次。新架构支持CI负载繁重的大型代码仓库及Coding Agent创建的大量小型仓库，其核心变化在于本地NVMe仅作为温缓存。
AI 根据报道生成 · 3 小时前更新
报道时间线
沿着报道，了解事件的不同侧面。
- InfoQ 中文Cursor 使用基于 S3 的 WAL 将 Git 存储扩展到每秒 300 多次 Push
Cursor 发布名为 Continuity 的 Git 存储架构，通过将 S3 上的预写日志（WAL）作为数据最终依据，不再依赖副本间的同步协调来保证一致性。在合成测试中，该架构在使用 S3 Express One Zone 时，读取能力随副本数量线性增长，Push 请求处理量超过每秒 300 次，同时支持 CI 负载繁重的大型代码仓库和 Coding Agent 创建的大量小型仓库。 该架构的核心变化在于本地 NVMe 仅作为温缓存而非权威副本，系统通过 Rendezvous Hashing 选择节点并利用 S3 原子比较并交换操作接受 Push 请求。WAL 更新通过 UDP Gossip 协议传播，平均读取耗时不到 10 毫秒，即使消息丢失也不影响数据正确性。此外，Git 压缩仅由主副本执行，其他副本直接从 S3 下载压缩后的 packfile，虽然减少了 CPU 开销但增加了带宽消耗。 这一设计引发了与数据库架构的比较，将 Git 存储当作数据库来设计，关注 Push 一致性、Force Push 事务及时间点恢复等问题。性能数据显示，使用 S3 Standard 时系统每秒最多处理 120 次 Push，而 S3 Express One Zone 可提升至 300 次以上，当吞吐量进一步提高时，Git 压缩成为新的性能瓶颈。事实层面确认了架构转变与测试数据，推断层面表明该方案可能降低大规模 Git 托管的协调成本，猜测层面需关注独立验证结果及长期带宽成本影响。
本事件热度走势
当前热度 9·可比范围峰值 10（10月13日 11:00）·近 24 小时可比范围变化 –
趋势仅比较持续完整观测到的相同主体，范围可能小于当前热度统计。移动指针或点击图表查看每小时热度；键盘可用左右方向键切换。