这是一个创建于 1762 天前的主题，其中的信息可能已经有所发展或是发生改变。
事情是这样的，我这里网络环境比较特殊，单线程只能够跑到大概 2MB/s 的网速，但是多线程可以到 50MB/s 。
在 rsync 同步的时候，速度比较慢，一开始我写了个 py 脚本，实现自动 split 文件到 tmp 目录，同时开启多个 rsync 拷贝多个文件，到远端再合并。
机缘巧合之下，我同一个 rsync 命令运行了两次，然后第二个命令以很快的速度加载到第一个命令的进度，两者又同时开始了同步，速度相同。
发现这个现象之后，我又用 urandom 新建了一个随机文件，同时开启 20 个 rsync 进程，我发现同步的速度增加了 20 倍，而且各个进程结束的时间不是完全一致的，最终用 rsync -c 参数重新 check 了一遍，也是成功通过校验，说明完成了同步。
查阅手册看到，rsync 好像是不支持多线程参数的，所以我称之为多进程同步，现在就想知道这个原理，是我误打误撞还是本身就有这个用法而我没看到。
因为 rsync 一开始不可能知道我想多开几个进程，所以不可能事先分块传输(我的人工方案)，也就不可能协商出来分块方案来同步进度。
而且查阅资料，其默认采用大小+修改时间的校验方法，并且默认新建临时文件，那么多个 rsync 进程之间获取到的临时文件大小肯定也不会一样，以此为起点也不太可能，我没加 inplace 参数，所以最后合并肯定还是由一个进程去做的，这就令我很迷惑。
最后，我参数里还带了压缩，对流的压缩就更不可能分块传输了吧，难不成是另有玄机？我这里多开了客户端，服务端那里究竟起了几个 rsync 进程来接收文件，这也是我实验没做出来的。
求大佬路过给小弟一个解释，实在迷惑。
附录：
我用的参数：
rsync -avhzP --exclude ".DS_Store" --exclude ".*" --append-verify 最后校验：
!! -c  | 1 msg7086 2020-12-19 23:14:47 +08:00 rsync 主要是断点续传。 append-verify 我倒是不太清楚会不会有奇怪的作用（或者副作用）。 但是我感觉应该会有重复传送的现象。你可以再测量一下实际传送的流量。 服务器上起了几个 rsync 进程的话，应该和客户端 rsync 进程数相同。 |
 | 2 oott123 2020-12-20 11:43:56 +08:00 via Android 你掐了秒表吗？ 应该是每个 rsync 进程都做了一遍重复的事情。 |
Select Language