rsync算法原理及使用

如果服务器之间需要保持某些文件的一致，我们可以使用scp来复制，如果需要长期保持一致，可以配合crontab脚本来使用。但是此时我们有更优的方式，就是rsync+crontab来实现定时增量传输保持文件一致。

rsync功能很强大，网上的资料也都很全，这里做一些简单的汇总。

rsync原理

这一小节内容大幅度转载了 RSYNC 的核心算法 的内容，因为原文章写的太好，就不再狗尾续貂了，感兴趣的可以直接查看原文。他的翻译原文是：The rsync algorithm。

rsync是linux下同步文件的一个高效算法，用于同步更新两处计算机的文件和目录，并适当利用查找文件中的不同块以减少数据传输。rsync的主要特点就是增量传输，只对变更的部分进行传送。

增量同步算法
假如我们现在需要同步两个文件保持一致，并且只想传送不同的部分，那么我们就需要对两边的文件做diff，但是这两个问题在两台不同的机器上，无法做diff。如果我们做diff，就要把一个文件传到另一台机器上做diff，但这样一来，我们就传了整个文件，这与我们只想传输不同部的初衷相背。于是我们就要想一个办法，让这两边的文件见不到面，但还能知道它们间有什么不同。这就是rsync的算法。

rsync同步算法
我们将同步源文件名称为fileSrc，同步目的文件叫fileDst。

1. 分块Checksum算法
首先，我们会把fileDst的文件平均切分成若干个小块，比如每块512个字节（最后一块会小于这个数），然后对每块计算两个checksum:

一个叫rolling checksum，是弱checksum，32位的checksum
另一个是强checksum，128位的，以前用md4，现在用md5 hash算法。
为什么要这样？因为若干年前的硬件上跑md4的算法太慢了，所以，我们需要一个快算法来鉴别文件块的不同，但是弱的adler32算法碰撞概率太高了，所以我们还要引入强的checksum算法以保证两文件块是相同的。也就是说，弱的checksum是用来区别不同，而强的是用来确认相同。

2. 传输算法
同步目标端会把fileDst的一个checksum列表传给同步源，这个列表里包括了三个东西，rolling checksum(32bits)，md5 checksume(128bits)，文件块编号。

同步源机器拿到了这个列表后，会对fileSrc做同样的checksum，然后和fileDst的checksum做对比，这样就知道哪些文件块改变了。

但是，聪明的你一定会有以下两个疑问：

如果我fileSrc这边在文件中间加了一个字符，这样后面的文件块都会位移一个字符，这样就完全和fileDst这边的不一样了，但理论上来说，我应该只需要传一个字符就好了。这个怎么解决？ 如果这个checksum列表特别长，而我的两边的相同的文件块可能并不是一样的顺序，那就需要查找，线性的查找起来应该特别慢吧。这个怎么解决？ 很好，让我们来看一下同步源端的算法。

3. checksum查找算法
同步源端拿到fileDst的checksum数组后，会把这个数据存到一个hash table（特殊的数据结构体，可以快速检索）中，用rolling checksum做hash，以便获得O(1)时间复杂度的查找性能。这个hash table是16bits的，所