云风的 BLOG

这次实现，我们去掉了目录和文件处理方式上的差异，一律都变成了以其内容的 hash 值为文件名（key）的数据块。仓库仅仅是一个 key-value 的数据仓库，以内容 hash (选用了 sha1 算法）为文件名放在仓库目录下。为了避免单个目录文件太多（对大多数文件系统不友好），把内容散列到最多 256 个子目录下。

普通文件就是完全没有修改过的文件本身；而目录是自己建立的索引信息。我采用的是文本格式，一行一个文件描述，记录有文件类型（文件 f 或目录 t ）hash 值，文件名。最终一个目录索引文件看起来是这样的：

d 10a34637ad661d98ba3344717656fcc76209c2f8 f0
f da39a3ee5e6b4b0d3255bfef95601890afd80709 f0_1.txt

这表示该目录下有一个子目录 f0 和一个文件 f0_1.txt 。

这样做会使得子目录下任何一个文件的改变，都会改变目录索引本身的 hash 值，进而会影响父目录的 hash 值。也就是说，整个仓库中的任何一点修改，都最终会影响到根目录的索引。

在接口上，我仅提供了从 hash 值 query 数据；修改根目录指针（一个 hash 值）；从文本路径查找最终对象的 hash 值等这么几个。

通过不同的根目录指针，我们可以让不同的历史版本存在于同一个仓库中，并且最大限度地重用版本间相同的数据。对于服务器/ PC 编辑器端，我们仅需要提供一个重建索引的操作方法。我们从根索引递归遍历下去，为每个目录创建出索引文件。

和 git 不同的是，我们可以不强制把本地文件系统（ git 的工作区）的文件复制到仓库中，而是在仓库中建立一个引用文件。引用文件的文件名使用 hash.ref 的命名方式，表示这个 hash 值对应的实际数据并不在仓库中，而是引用的外部文件。其内容就是外部文件的路径、hash 值和时间戳。由于不同的文件可能内容完全相同，因为一个引用文件可以指向不同的路径，我们会在引用信息中用多行指名；这样在一个文件失效后，还可以依次索引到没有变更的文件。

在快速重建仓库索引时，发现有引用文件，就只比较时间戳。时间戳相同就不必重算 hash 值。

程序以 c/s 结构运行时，在移动设备上先建立一个空的镜像仓库，同步 PC 端的资源仓库。运行流程是这样的：

首先在客户端启动的时候，向服务器索取一个根索引的 hash ，在本地镜像上设定根。

客户端请求一个文件路径时，从根开始寻找对应的目录索引文件，逐级查找。如果本地有所需的 hash 对象，就直接使用；否则向服务器请求，直到最后获得目标文件。api 的设计上，open 一个资源路径，要么返回最终的文件，要么返回一个 hash ，表示当前还缺少这个 hash 对象；这样，可以通过网络模块请求这个对象；获得该对象后，无须理会这个对象是什么，简单写入镜像仓库，然后重新前面的过程，再次请求未完成的路径，最终就能打开所需的资源文件。

这个方式的巧妙之处在于，不需要传统的版本号管理的方式，就可以完美处理多版本问题。客户端和服务器同步过程，只有第一步的根 hash 同步是强制的，且仅同步一个 hash 值。如果移动设备上有多个不同的版本（比如在不同的开发人员的机器上切换），在一开始同步完根 hash 后，完全不用再有任何网络传输。这个过程比 git 切换版本还要快，因为我们在移动设备上没有工作区的概念，不需要在切换版本时拷贝文件到工作区。

在最终版本发布时，也可以做简单的打包，避免小文件过多。简单的把仓库文件打包即可。仓库中就是简单的 key-value 结构，处理包文件比本地文件目录更简单。

同时，发布版本的更新要比传统版本号方式要简单的多。

在发布产品中，我们多半不提供开发期这种按需索要缺少的资源的工作方式，而是将当前版本的所有数据都提前下载后。在这种预下载模式下客户端在启动时从服务器索取一个根 hash ，如果和本地的根相同，则说明版本没有更新；否则，将自己的根 hash （代表了一个版本）发送给服务器。

服务器理论上保留有所有历史发布过的版本，所以会找到这个历史版本。这时服务器可以自己对比这两个版本，计算出客户端缺失的对象，然后打包发送给客户端。

当然，服务器可以缓存一些常见的版本（因为大部分玩家都会停留在上个版本），省略这步比较操作，直接让玩家从 CDN 下载打包好的更新包；对于不常见版本，可以计算出一个最接近的更新包（在 CDN 上），然后把更新包中没有的文件单独打包出来。

这个流程其实和 git 的 fetch 操作非常类似，只不过我们可以针对网游的特质，做一点优化罢了。

因为我们的引擎几乎全部是用 lua 实现，包括这里提到的资源仓库的相关模块，所以理论上这块代码本身也可以被这个仓库管理。这样，还涉及一些代码自举和自更新的流程，这一块的细节也有点意思，我打算过两天另外写一篇 blog 介绍。