正文
Rsync原理的简单学习
前言
工作这么多年, 感觉对自己帮助最大的是rsync.
用了很多rsync的脚本, 甚至因为这个脚本授权了两个专利.
但是昨天晚上在跟高手聊天时发现 自己对rsync 其实不了解.
对他底层的一些算法和实现,其实都是不清不楚的.
说实话感触挺深的.
以后自己用东西,还是必须深入学习的.
网上资料的学习
假定在名为 α 和 β 的两台计算机之间同步相似的文件 A 与 B，其中 α 对文件A拥有访问权，
β 对文件 B 拥有访问权。并且假定主机 α 与 β 之间的网络带宽很小。
那么 Rsync 算法将通过下面的五个步骤来完成：
β 将文件 B 分割成一组不重叠的固定大小为 S 字节的数据块。最后一块可能会比 S 小。
β 对每一个分割好的数据块执行两种校验：一种是32位的滚动弱校验，另一种是128位的 MD4 强校验。
β 将这些校验结果发给 α。
α 通过搜索文件 A 的所有大小为 S 的数据块（偏移量可以任选，不一定非要是 S 的倍数），
来寻找与文件B 的某一块有着相同的弱校验码和强校验码的数据块。
这项工作可以借助滚动校验的特性很快完成。
α 发给 β 一串指令来生成文件 A 在 β 上的备份。
这里的每一条指令要么是对文件 B 经拥有某一个数据块而不须重传的证明，要么是一个数据块，
这个数据块肯定是没有与文件 B 的任何一个数据块匹配上的。
From https://blog.csdn.net/JineD/article/details/111871170
一些简单理解
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.534s
tar.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
