rsync 是怎么实现多进程(假)分块上传的？多开 rsync 的时候是如何复制的文件？
資深大佬 : Licsber 8
事情是这样的，我这里网络环境比较特殊，单线程只能够跑到大概 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 大佬有話說 (4)