深入了解 GitHub 全新的 Git 存储架构
BestBlog编程类文章 · 软件开发
📌 One-Sentence Summary GitHub 全新的 Git 存储架构 Rubicon 使用 Azure Blob Storage 和 Ref-CAS 将存储与计算解耦，支持每秒数千次写入，助力大规模智能体驱动开发。 📝 Summary GitHub 全新的 Git 存储架构 Rubicon 通过迁移至 Azure Blob Storage，并引入用于管理引用的 Ref-CAS，应对智能体驱动开发的指数级增长。该系统通过按引用进行串行化，每秒可支持数千次写入，同时允许并发写入不同分支。虚拟副本独立处理读写，而压缩节点则在后台执行维护工作。这一设计让各种规模的仓库——从个人项目到大型单体仓库——都能实现可扩展、低延迟的 Git 操作。 💡 Main Points 按引用进行串行化，提升写入吞吐量 将写入仲裁范围限定在单个引用，而非整个仓库，使多个智能体可以并发推送到不同分支，在保证正确性的同时实现每秒数千次写入。 虚拟副本将存储与计算解耦 虚拟副本是可随时替换的计算节点，会缓存来自 Azure Blob Storage 的数据。读写操作可以独立扩展，且正确性不依赖任何单一节点。 Ref-CAS 使用共识协议管理引用状态 复制日志服务 Ref-CAS 使用比较并交换事务处理引用更新，实现高吞吐、有序写入，同时将对象数据保存在持久化的 Blob Storage 中。 后台压缩保障读取性能 专用压缩节点在后台合并 pack，不影响虚拟副本，确保随着写入量增加，pack 数量保持平稳，读取延迟也保持一致。 架构支持全球化、可扩展的智能体驱动开发 统一架构让任何仓库都能处理智能体驱动的工作负载，无需特殊处理；未来还计划改进部分副本和全球分布等能力。 💬 Key Quotes 在更早的一篇博客文章中，我们阐述了新一代 Git 存储架构背后的两项原则：尽量减少协调，以及将存储与计算解耦。 采用按引用进行串行化后，只有竞争同一个引用的写入才需要相互等待。实际上，仓库中的大多数写入都会涉及不同的引用——例如，智能体和开发者分别推送到自己的分支——因此它们不再需要相互等待。 虚拟副本由一组可随时替换的计算节点构成，可处理读取、写入或两者兼有的任务。虚拟副本的本地磁盘是缓存，可以随时重建。 Ref-CAS 中的每次引用更新都是通过仲裁组提交的比较并交换操作……智能体大多推送到自己的分支，因此大多数更新不会发生竞争，并且可以并行复制。 📊 Article Meta AI Screening： 92 Featured： Yes Source： The GitHub Blog Author： Karthik Raman Category： 软件编程 Language： 英文 Read Time： 13 min Word Count： 3241 Tags： 编程与工程 , 系统设计 , 性能优化 , 云原生 / DevOps , 分布式系统 Read Full Article