Dropbox差异同步算法rsync及其改进算法原理

之前用过rsync很多次，只知道可以做差异同步也没研究过原理。所谓差异同步是指只通过传输两文件的差异部分将两文件同步到一致，自己取的称谓，不知道学术术语是什么。差异同步算法中最有名的就是rsync系列了。

    近来研究Dropbox，想看看它的同步怎么做的，没找到官方资料，不过据推测应该用的就是rsync，于是，看看鼎鼎大名的rsync是怎么实现的吧。

    rsync算法要解决的问题很简单：A和B两个文件在两台服务器中，要将A同步到与B一致，要求尽量减少同步带来的网络传输开销。

    rsync基本算法

    先说基本的rsync算法，并不复杂，简单的说是三步：

    1、按固定大小将A分为多块，每块都计算出一个32位的滚动哈希值和一个128位的MD4（有些也用MD5），发给B一端。

    2、B一端从位置0开始按的同样块大小的滚动哈希值，查找看是否命中A给的某个滚动哈希值，若匹配，则表明B文件中的这块内容与对应的A中的那块内容很可能是一致的，但由于32位的哈希值强度不够，因此再计算MD4，若还是匹配，则确认是一致内容，这时B发给A端匹配的段号。对于那些不能匹配的内容，则发给A端原始内容。

    3、A端得到B端给的匹配信息，构造一个与B一致的复本，若是匹配的块，则拷贝原A文件中对应的块，若是不匹配内容则追加之。

    滚动哈希值的设计基于Adler32算法，使得2~K+1字节的哈希可以根据1~K字节哈希和1、K+1字节的内容快速计算得到，这可以提高从位置0开始依次计算滚动哈希值的效率。

    据试验一般来说块大小取500~1000字节效果比较好。

    rsync初级优化

    在上述基本算法之上可以进行一些初级的优化，比如：

    1、传输数据再做压缩

    2、先用更短小的哈希值作同步，然后比较同步后二者MD5，如果不一样，再换用更长的哈希值，如此在大多数情况下可以减小哈希值的传输开销。因为如果用500字节的块大小的话，一个32位的滚动哈希值和一个128位的MD4会占用原始数据1/25的开销，并不太小

    基于rsync的改进算法

    基于rsync的改进算法主要有多轮rsync和本地rsync两个。

    多轮rsync的原理简单的说就是先用较大的块大小按rsync的方法处理一轮，但只传输那些命中的块，那些没命中的数据称为“空洞”，按较小的块大小再按rsync的方法又处理一轮，如此双可能产生规模更小的“空洞”，如此按来一轮，直到块大小到配置的最小块大小为止。最后一轮跟原始rsync是一样的，当然只处理上一轮遗留下来的“空洞”。多轮rsync在理论上可以将最差情况下的复杂度（以传输的数据量称是）从原rsync的O(sqrt(n))提高到O(ln n)。试验中有时多轮rsync可以比原rsync有10倍的提升，但大部分情况下是类似的。

    本地rsync则是直接更新A到与B一致，原始rsync算法是需要构造一个与B一致的副本。为实现这一点，需要先拿到所有匹配信息后进行拓扑排序，再依次应用，是有些复杂的。