rsync是一种文件差异传输的算法，特点是高效且相似块识别率较高。具体算法这边就不赘述，网上很多，官方文档也描述的很清楚。
rsync提高文件比对效率的一个核心算法之一就是rolling checksum，官方使用的是Alder32 Hash算法。
在我经历的一个项目中，我们在Windows Azure中实现文件差异传输模块，我使用rsync时发现在本地测试速度非常理想，但一旦放到实际环境中则让人完全无法接受。
于是走上了漫长而痛苦的优化之路。。。。。。
除了外部的一些调优，最终我还是决定在rsync的算法上开刀。经过冥思（真的就只是坐着不动，连续几个小时的思考），有一个想法跳了出来 -- Jump Rolling！
rsync中的rolling是一个痛苦漫长计算消耗极大的过程，为了更好的比对文件差异，rsync是逐个字节（byte）进行计算hash比对的，听上去很恐怖，不过如果你看了rolling checksum的算法就知道这个还是很巧妙的提高了rolling的效率。
当rolling了一个chunk的数据发现匹配了，这样很好，标记为匹配，接着从下个chunk开始计算。但如果一直不匹配，rolling就必须一个字节一个字节的进行。
假设一下我们A和B两个文件长度都为100，分成10块每个chunk长度为10：
第一种情况：
A和B完全是相同的两个文件
Rolling开始计算第一块，匹配，接着计算第二块，匹配…… 一共计算5次弱hash和强hash，结束。
第二种情况：
A和B完全不同
Rolling开始计算第一块，不匹配，向后rolling步进为1，直到文件结束都不匹配，一共rolling了90次，结束。（注意直接计算一个chunk的弱hash比rolling一个字节消耗要大，但rolling仍然是非常消耗时间和CPU的计算过程）
好了，到这里我们发现对于匹配度高的文件，rsync计算神速，但匹配度低的文件由于要不断rolling，计算速度就陡然降低很多。
我想到的是我们来根据前面块的计算去“预测”后面块的匹配度。（这怎么可能预测！！！）
是的，预测的算法很多，我使用的是一种比较简单的逻辑“如果出现rolling一整个chunk都没有找到匹配，则预测下个chunk也不匹配”，然后直接跳过下个chunk不计算；进阶的预测是“如果继续出现rolling一整个chunk不匹配，则预测接下来N个chunk也不匹配”，N是关于“连续出现不匹配次数M”的一个函数,函数设计的好可以提高速度又不至于降低太多精度，我用的函数的n = 2^(m-1), 然后根据chunk数量设置了阀值避免跳跃跨度过高（阀值函数也可以自己设计，这边我参考的是rsync的分块算法来完成我的阀值算法）。最后补充规则“当rolling到匹配块时，N重置”，这个规则提高计算结果的匹配精度。OK，这个就是RexSync的精髓了。
再来用RexSync分析状况二：
Rolling开始计算第一块，不匹配，，向后rolling步进为1，直到第2个chunk结束仍然不匹配，跳过chunk3计算chunk4不匹配，rolling chunk5不匹配，跳过6和7计算chunk8不匹配，rolling chunk9不匹配，跳过chunk10结束。rolling了30次，比起rsync的90次降低很多。当然这个例子太简单，实际情况下降低的更多。
好了，这样jump啊jump，精度损失如何？
实际测试结果，精度比rsync下降0-10%左右，当然理论极端值是精度下降到0（除非你根据RexSync的特征制造专门的文件啊亲你真可爱,jump过的chunk都匹配是要闹哪样！）。不过牺牲了一点精度，性能确实极大提高了。你不喜欢牺牲精度？看看标题我怎么写的！！
之前在公司写过正式文档，这篇随便乱写的。sign~