39.2　Git式云存储畅想

GitHub是Git风格的云存储，但缺乏像之前提到的云存储提供的傻瓜式服务，只有Git用户才能真正利用好，这大大限制了Git在云存储领域的推广。下面是我的一个预言：一个结合了Git和傻瓜式云存储的网络存储服务终将诞生。新的傻瓜式云存储将有下列特征：

1.差异同步传输

用户体验最为关键的是网络传输，如果用Git可以在同步时实现仅对文件差异进行数据传输，会大大提高同步效率。之所以现有的在线备份系统实现不了“差异同步传输”，是因为没有在本地对上一次同步时的数据做备份，只能通过时间戳或文件的哈希值判断文件是否改变，而无法得出文件修改前后的差异。

可以很容易地测试云存储软件的网络传输性能。准备一个大的压缩包（使同步时的压缩传输可以忽略），测试一下同步时间。再在该文件后面追加几个字节，然后检查同步时间。比较前后两个时间，就可以看出同步是否实现了仅针对差异的同步传输。

2.可预测的本地及云端存储空间的占用

要想实现前面提到的差异同步传输，就必须在本地保存上一次同步时文件的备份。Subversion是用一份冗余的本地拷贝实现的，这样本地存储大小是实际文件的两倍。Git在本地是完全版本库，占用空间的逐渐增加会变得不可预测。

使用Git实现云存储，就要解决在本地及在服务器端空间占用不可预测的问题。对于服务器端，可以采用前面介绍的Gistore软件重整版本库的方法，或者通过基于历史版本重建提交然后变基来实现提交数量的删减。对于客户端来说，只保留一个提交就够了，类似Subversion的文件的原始拷贝，这就需要在客户端基于Git原理重新实现。

3.更高效的云端存储效率

现有的云存储效率不高，很有可能因为冗余备份而导致存储超过配额，即使服务提供商的配额计算是以最后一个版本计算的，实际的磁盘占用还是很可观的。

Git底层实现了一个对内容跟踪的文件系统，相同内容的文件即使文件名和目录不同，在Git看来都是一个对象并用一个文件存储（文件名是内容相关的SHA1哈希值）。因此Git方式实现的云存储在空间的节省上有先天的优势。

4.自动进行冲突解决

冲突解决是和文件同步相关的，只有通过“差异同步传输”解决了同步的性能瓶颈，才能为冲突解决打下基础。先将冲突的各个版本都同步到本地，然后进行自动冲突解决，如果冲突无法自动解决，再提示用户手工解决冲突。还有，如果在手工冲突解决时引入类似kdiff3一样的工具，对用户会更有吸引力。

5.Git提交中引入特殊标识

如果使用变基或其他技术实现备份提交数量的删减，就会在云端的提交与本地数据的合并上产生问题。可以通过为提交引入特殊的唯一性标识，不随着Git变基而改变，就像在Gerrit中的Change-Id标签一样。

我相信，基于Git的文件系统及传输机理可以实现一个更好用的云存储服务^[1]。

[1]在本书基本完稿时，听说了一个名为SparkleShare的项目，似乎就是一个基于Git的云存储方案。网址：http://sparkleshare.org/。