尽管 Git Ketch 项目开发才刚刚开始，谷歌公司已经对外宣布了他们的第一个Git 项目——Git Ketch，一个多主机Git 管理系统，能够通过访问多个Git 服务器来复制信息，以确保复制信息的复原性和可扩展性。所做的这些改变都是基于原有用Java 搭建的名为JGit 的Git 服务器基础之上的，虽然这里面的其它Git 服务器可能是多主机群集的一部分。
最初设计 Git 的目的是将 Git 打造成一个分布式源代码管理库系统，但是大多数组织都采用了一个集中式的方式：采用一个带有“黄金副本”代码的主库，所有开发者会在这个主库上做修改，然后以最终版本作为更新基础；尽管所有改动能从开发者的私库里直接调取，但很少有这么做的。
只不过这种集中式方法也会导致单点故障。不过别担心，JGit 提供了部分解决方案，那就是通过它的分布式文件系统（DFS）的存储选项。此选项仅能解决部分问题，因为 JGit 只定义了一组抽象类，而这组抽象类又定义了 DFS 存储协议，但支持数据复制和创建抽象类实现的整体架构则是由用户自己设计的。这就意味着组织已投入相当大的资源——为实现 JGit DFS，项目组暂时还不能将 JGit DFS 大范围推广使用，谷歌是少有的几个掌握 DFS 实现的组织之一。
Ketch 所遵循的策略有些与众不同，不仅仅可以定义一个能够复制 DFS 数据的 Git 服务器，Ketch 还可以假定现存的多个普通 Git 服务器可以互相之间数据和状态同步，因此被称为“多主机”。在任何一个制定的节点上，这些服务器都可以当作“主机”来使用，其余的服务器当作“从机”来利用。任何时候向任何一台服务器发送请求，这个“请求”都会被转发给“主机”，该“主机”将会向所有其他服务器发送推送请求，一旦绝大多数“从机”服务器已经确认推送请求成功，“主机”会向初始呼叫对象确认操作已成功。这一机制是基于 Raft 算法，此算法能够确保至少大多数服务器能够接收已经做了变更的请求；任何服务器上的数据丢失，都可以通过其它服务器同步过来。目前，只有 JGit 服务器可以充当“主机”，虽然在多主机集群里任何 Git 服务器实现的原子推送都可以充当一个参与服务器。
这些已经提出来的改变均可以在 JGit 内部 Gerrit 里看到，关于未来在工具上的改进细节及进展都可以从 JGit 的电子邮件分发列表里获得。
查看英文原文： Google Kick-Starts Git Ketch: A Fault-Tolerant Git Management System
评论