Rsync原理的简单学习
前言
工作这么多年, 感觉对自己帮助最大的是rsync.
用了很多rsync的脚本, 甚至因为这个脚本授权了两个专利.
但是昨天晚上在跟高手聊天时发现 自己对rsync 其实不了解.
对他底层的一些算法和实现,其实都是不清不楚的.
说实话感触挺深的.
以后自己用东西,还是必须深入学习的.网上资料的学习
假定在名为 α 和 β 的两台计算机之间同步相似的文件 A 与 B，其中 α 对文件A拥有访问权，
β 对文件 B 拥有访问权。并且假定主机 α 与 β 之间的网络带宽很小。
那么 Rsync 算法将通过下面的五个步骤来完成：
β 将文件 B 分割成一组不重叠的固定大小为 S 字节的数据块。最后一块可能会比 S 小。
β 对每一个分割好的数据块执行两种校验：一种是32位的滚动弱校验，另一种是128位的 MD4 强校验。
β 将这些校验结果发给 α。
α 通过搜索文件 A 的所有大小为 S 的数据块（偏移量可以任选，不一定非要是 S 的倍数），
来寻找与文件B 的某一块有着相同的弱校验码和强校验码的数据块。
这项工作可以借助滚动校验的特性很快完成。
α 发给 β 一串指令来生成文件 A 在 β 上的备份。
这里的每一条指令要么是对文件 B 经拥有某一个数据块而不须重传的证明，要么是一个数据块，
这个数据块肯定是没有与文件 B 的任何一个数据块匹配上的。一些简单理解
rsync的检查主要是通过 循环区块的处理.
并且感觉 他们并不是完全按照区块进行md4或者是md5的检查.
或者仅是32字节做一下简单的 checksum 能够极大额减少文件需要传输的字节.
昨天刚好学习了下split 和 cat 进行文件的切分和合并.
联想到之前BT下载时都是分块下载. 其实感觉道理应该都是相通的.
感觉可以通过一个实验的方式进行处理.
下面就是实验的时间.实验的思路
公司内上传文件->阿里云的机器
通过 avz 参数查看文件上传时间 以及一些加速特性.
通过cat的方式进行一些文件的变更, 验证他的速度.
cat 使用两种模式 尾部添加文件和头部添加文件.
验证rsync是否可以智能化的继续拧处理.
以及验证压缩文件和非压缩文件的一些处理机制.实验结果分析
1. rsync 是分块传输. 大文件修改一部分时效率非常高,加速比超过30 很正常.
2. rsync 进行计算的原理很只能.不管是文件头新增和文件尾部新增都可以准确识别.
3. rsync 的传输可以进行压缩, 并且压缩比非常可观. 在地网络带宽情况下的性能很好.
4. rsync 的一致性检查应该是 循环模式进行check或者是md4. 不适用更高级别的checksum,避免算法消耗更多的CPU测试过程-原始文件测试-tar包
262M 8月 16 2021 vmware_exporter.tar
262M的文件 上传完 24秒. 加速比是 2.71
time rsync -avz vmware_exporter.tar root@xx.xx.xx.xx:/
Warning: Permanently added 'xx.xx.xx.xx' (ED25519) to the list of known hosts.
sending incremental file list
vmware_exporter.tar
sent 100,954,996 bytes received 35 bytes 4,120,613.51 bytes/sec
total size is 273,871,872 speedup is 2.71
real 0m24.456s测试过程-原始文件测试-tar包-重传
不做任何修改, 直接进行文件传输. 发现不到一秒钟就可以传输完成
提示仅接收了12个字节. 怀疑应该是整个文件的 checksum. 判断完全一致就没有继续传输.
所以效率很快.
time rsync -avz vmware_exporter.tar root@xx.xx.xx.xx:/
Warning: Permanently added 'xx.xx.xx.xx' (ED25519) to the list of known hosts.
sending incremental file list
sent 53 bytes received 12 bytes 130.00 bytes/sec
total size is 273,871,872 speedup is 4,213,413.42
real 0m0.786s测试过程-尾端修改文件-tar包
time cat vmware_exporter.tar zhaobsh.tar.gz >/root/vmware_exporter.tar
将文件进行一下融合增加
273M /root/vmware_exporter.tar
大概增加了11M的大小
再次进行传输, 大约7秒钟完成. 发送字节是 不到10m. 接收了 110k.
加速比是30. 感觉他做的压缩效率比tar.gz 还要高.
因为 zhaobsh.tar.gz的大小为:
11,893,322 12月 5 23:09 zhaobsh.tar.gz
time rsync -avz /root/vmware_exporter.tar root@xx.xx.xx.xx:/
Warning: Permanently added 'xx.xx.xx.xx' (ED25519) to the list of known hosts.
sending incremental file list
vmware_exporter.tar
sent 9,372,579 bytes received 115,924 bytes 1,265,133.73 bytes/sec
total size is 285,765,194 speedup is 30.12
real 0m7.463s测试过程-头部修改文件-tar包
time cat zhaobsh.tar.gz vmware_exporter.tar >/home/vmware_exporter.tar
将文件进行一下头部增加.
文件大小类似,发现结果为: 7秒钟左右完成.
加速比也是一样的. 上传的文件大小也是类似的.
time rsync -avz /home/vmware_exporter.tar root@xx.xx.xx.xx:/home/
Warning: Permanently added 'xx.xx.xx.xx' (ED25519) to the list of known hosts.
sending incremental file list
vmware_exporter.tar
sent 9,372,112 bytes received 115,924 bytes 1,265,071.47 bytes/sec
total size is 285,765,194 speedup is 30.12
real 0m7.534star.gz包的加速比验证
加速比为 1
原始文件的大小为: 110400785 /root/vmware_exporter.tar.gz
110,400,785 发送比实际的total size 要下, 说明效率还是很高的.
time rsync -avz /root/vmware_exporter.tar.gz root@xx.xx.xx.xx:/home/
Warning: Permanently added 'xx.xx.xx.xx' (ED25519) to the list of known hosts.
sending incremental file list
vmware_exporter.tar.gz
sent 109,955,873 bytes received 35 bytes 5,638,764.51 bytes/sec
total size is 110,400,785 speedup is 1.00
real 0m19.259s
