前言
最近需求里面有做服务器文件同步这一块儿，用到了rsync，于是简单了解了一下rsync的功能和算法原理，主要从下面几个点来学习：
- 什么是rsync
- rsync算法原理和工作过程
- 从工作原理分析rsync的适合场景
什么是rsync
rsync - a fast, versatile, remote (and local) file-copying tool
Rsync is a fast and extraordinarily versatile file copying tool. It can copy locally, to/from another host over any remote shell, or to/from a remote rsync daemon. It offers a large number of options that control every aspect of its behavior and permit very flexible specification of the set of files to be copied. It is famous for its delta-transfer algorithm, which reduces the amount of data sent over the network by sending only the differences between the source files and the existing files in the destination. Rsync is widely used for backups and mirroring and as an improved copy command for everyday use.
上面是rsync官网的介绍，简单来说rsync就是一个复制工具，它通常用来实现两台机器间的文件同步（本机和远程主机），但不能实现远程主机A和远程主机B之间的文件同步。
rsync算法原理和工作过程
假设我们有两台主机HostA 和HostB，A和B分别拥有自己的文件file_c和file_d，我们用rsync来实现将HostA的file_c同步给HostB的file_d
整个同步过程可以分为下面六个步骤：
1.HostA告诉HostB要同步文件file_c
2.HostB收到消息后，将文件B划分为一系列大小固定的数据块，并以chunk号码对数据块进行编号，同时还会记录数据块的起始偏移地址以及数据块长度。显然最后一个数据块的大小可能更小
3.HostB对file_d的每个数据块根据其内容都计算两个校验码：32位的弱滚动校验码(rolling checksum)和128位的MD4强校验码(现在版本的rsync使用的已经是128位的MD5强校验码)。并将file_d计算出的所有rolling checksum和强校验码跟随在对应数据块chunk[N]后形成校验码集合，然后发送给HostA
需要注意，不同内容的数据块计算出的rolling checksum是有可能相同的，但是概率非常小
4.当HostA接收到file_d的校验码集合后，HostA将对此校验码集合中的每个rolling checksum计算16位长度的hash值，并将每216个hash值按照hash顺序放入一个hash table中，hash表中的每一个hash条目都指向校验码集合中它所对应的rolling checksum的chunk号码，然后对校验码集合根据hash值进行排序，这样排序后的校验码集合中的顺序就能和hash表中的顺序对应起来
同样需要注意，不同rolling checksum计算出的hash值也是有可能会相同的，概率也比较小，但比rolling checksum出现重复的概率要大一些
5.随后HostA将对file_c进行处理。处理的过程是从第1个字节开始取相同大小的数据块，并计算它的校验码和校验码集合中的校验码进行匹配。如果能匹配上校验码集合中的某个数据块条目，则表示该数据块和文件B中数据块相同，它不需要传输，于是HostA直接跳转到该数据块的结尾偏移地址，从此偏移处继续取数据块进行匹配。如果不能匹配校验码集合中的数据块条目，则表示该数据块是非匹配数据块，它需要传输给HostB，于是HostA将跳转到下一个字节，从此字节处继续取数据块进行匹配。注意，匹配成功时跳过的是整个匹配数据块，匹配不成功时跳过的仅是一个字节
上面说的数据块匹配只是一种描述，具体的匹配行为需要进行细化。rsync算法将数据块匹配过程分为3个层次的搜索匹配过程。
首先，HostA会对取得的数据块根据它的内容计算出它的rolling checksum，再根据此rolling checksum计算出hash值。
然后，将此hash值去和hash表中的hash条目进行匹配，这是第一层次的搜索匹配过程，它比较的是hash值。如果在hash表中能找到匹配项，则表示该数据块存在潜在相同的可能性，于是进入第二层次的搜索匹配。
第二层次的搜索匹配是比较rolling checksum。由于第一层次的hash值匹配到了结果，所以将搜索校验码集合中与此hash值对应的rolling checksum。由于校验码集合是按照hash值排序过的，所以它的顺序和hash表中的顺序一致，也就是说只需从此hash值对应的rolling chcksum开始向下扫描即可。扫描过程中，如果file_c数据块的rolling checksum能匹配某项，则表示该数据块存在潜在相同的可能性，于是停止扫描，并进入第三层次的搜索匹配以作最终的确定。或者如果没有扫描到匹配项，则说明该数据块是非匹配块，也将停止扫描，这说明rolling checksum不同，但根据它计算的hash值却发生了小概率重复事件。
第三层次的搜索匹配是比较强校验码。此时将对file_c的数据块新计算一个强校验码(在第三层次之前，只对file_c的数据块计算了rolling checksum和它的hash值)，并将此强校验码与校验码集合中对应强校验码匹配，如果能匹配则说明数据块是完全相同的，不能匹配则说明数据块是不同的，然后开始取下一个数据块进行处理。
之所以要额外计算hash值并放入hash表，是因为比较rolling checksum的性能不及hash值比较，且通过hash搜索的算法性能非常高。由于hash值重复的概率足够小，所以对绝大多数内容不同的数据块都能直接通过第一层次搜索的hash值比较出来，即使发生了小概率hash值重复事件，还能迅速定位并比较更小概率重复的rolling checksum。即使不同内容计算的rolling checksum也可能出现重复，但它的重复概率比hash值重复概率更小，所以通过这两个层次的搜索就能比较出几乎所有不同的数据块。假设不同内容的数据块的rolling checksum还是出现了小概率重复，它将进行第三层次的强校验码比较，它采用的是MD4(现在是MD5)，这种算法具有"雪崩效应"，只要一点点不同，结果都是天翻地覆的不同，所以在现实使用过程中，完全可以假设它能做最终的比较。
数据块大小会影响rsync算法的性能。如果数据块大小太小，则数据块的数量就太多，需要计算和匹配的数据块校验码就太多，性能就差，而且出现hash值重复、rolling checksum重复的可能性也增大；如果数据块大小太大，则可能会出现很多数据块都无法匹配的情况，导致这些数据块都被传输，降低了增量传输的优势。所以划分合适的数据块大小是非常重要的，默认情况下，rsync会根据文件大小自动判断数据块大小，但rsync命令的"-B"(或"--block-size")选项支持手动指定大小，如果手动指定，官方建议大小在500-1000字节之间。
6.当HostA发现是匹配数据块时，将只发送这个匹配块的附加信息给HostB。同时，如果两个匹配数据块之间有非匹配数据，则还会发送这些非匹配数据。当β主机陆陆续续收到这些数据后，会创建一个临时文件，并通过这些数据重组这个临时文件，使其内容和A文件相同。临时文件重组完成后，修改该临时文件的属性信息(如权限、所有者、mtime等)，然后重命名该临时文件替换掉B文件，这样file_c就和file_d保持了同步
从工作原理分析rsync的适用场景
(1).rsync两端耗费计算机的什么资源比较严重？
从前文中已经知道，rsync的sender端因为要多次计算、多次比较各种校验码而对cpu的消耗很高，receiver端因为要从basis file中复制数据而对io的消耗很高。但这只是rsync增量传输时的情况，如果是全量传输(如第一次同步，或显式使用了全量传输选项"--whole-file")，那么sender端不用计算、比较校验码，receiver端不用copy basis file，这和scp消耗的资源是一样的。
(2).rsync不适合对数据库文件进行实时同步。
像数据库文件这样的大文件，且是频繁访问的文件，如果使用rsync实时同步，sender端要计算、比较的数据块校验码非常多，cpu会长期居高不下，从而影响数据库提供服务的性能。另一方面，receiver端每次都要从巨大的basis file(一般提供服务的数据库文件至少都几十G)中复制大部分相同的数据块重组新文件，这几乎相当于直接cp了一个文件，它一定无法扛住巨大的io压力，再好的机器也扛不住。
所以，对频繁改变的单个大文件只适合用rsync偶尔同步一次，也就是备份的功能，它不适合实时同步。像数据库文件，要实时同步应该使用数据库自带的replication功能。
(3).可以使用rsync对大量小文件进行实时同步。
由于rsync是增量同步，所以对于receiver端已经存在的和sender端相同的文件，sender端是不会发送的，这样就使得sender端和receiver端都只需要处理少量的文件，由于文件小，所以无论是sender端的cpu还是receiver端的io都不是问题。
但是，rsync的实时同步功能是借助工具来实现的，如inotify+rsync，sersync，所以这些工具要设置合理，否则实时同步一样效率低下，不过这不是rsync导致的效率低，而是这些工具配置的问题。
