GitHub 如何破解 Git 的规模化难题
Git at any scale
Git 最初是为 Linux Kernel 设计的分布式版本控制系统，但在企业规模化应用中，其分布式特性反而成了瓶颈。文章深入剖析了 GitHub 在扩展 Git 仓库时遇到的技术挑战：从 Packfiles 的存储限制到分布式文件系统的失败尝试。最终，GitHub 通过 Spokes 架构实现了应用层复制，在保持数据强一致性的同时，利用本地 NVMe 磁盘解决了性能与可用性的矛盾。这一历程揭示了在保留 Git 核心协议的前提下，如何通过架构创新实现大规模托管。
当 Linus Torvalds 设计第一个版本时，他心中只有一个特定的使用场景：他自己的需求。
- eatonphil
> “扇出”（fan-out）通过一种名为 3PC（三阶段提交）的经典共识算法进行同步，因此只有当大多数节点确认时，推送才会被接受。
3PC 难道不是要求所有节点达成一致，而不仅仅是大多数吗？
- brasic
这篇文章作者的名声之盛，怎么强调都不为过。GitHub 内部系统中所有优秀的部分似乎都打着他的烙印（我意识到，这句话在今天听起来和几年前感觉大不相同）。我们在 GitHub 共事的时间重叠不多，但得知他如今在 cursor 工作，让我对他们工程团队的评价瞬间飙升。
- biwills
> 那共识呢？选举呢？给定仓库的主服务器是哪台？这些都不重要！这里没有状态，也没有共识。任何服务器都可以是主服务器。所有对预写日志（write-ahead log）的更新都通过 S3 上的原子比较并交换（CAS）操作进行同步，因此任何仓库实例接收推送都是安全的。
再次被 S3 这项惊人的工程成就所震撼（99.999999999% - 11 个 9 的持久性）[1]
1: https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDu...