使用 --remove-source-files 进行多个 rsync 进程

Question 1

不，实际行为是不可预测的，但有可能多个实例会同时尝试复制同一个文件，从而浪费带宽，并且可能会发生不好的事情。

但是，巧妙地使用--include和--exclude可能会在这里很方便：

rsync -avP \
    --include '*/' --include '[a-g]*' --exclude '*' \
    source.host:path/to/source/ path/to/dest/

此命令将仅发送以字母开头的文件a至g。您可以为字母表的其他部分设置并行传输。

最后，一旦所有传输完成，你应该运行你的原来的再次执行 rsync 命令（请注意，我省略了--remove-source-files命令）以确保发生的任何奇怪现象都得到消除，并且原始过滤器遗漏的任何文件（可能是点文件？）也得到了传输。

顺便说一句，始终在源目录和目标目录上加上最后的斜杠（例如path/to/dest/），否则rsync可能不会达到您预期的效果！

然而，rsync 并不是第一次复制文件的最有效方法，尤其是在延迟较高的情况下（它主要用于后续更新过程）。

最好使用tar将数据流式传输到ssh：

ssh source.host tar -C path/to/source/ cfj - . | tar -C path/to/dest/ xfj -

这会将数据打包并压缩成连续的流，通过ssh隧道传输，返回到tar本地端，然后在一个命令中扩展回文件，并且 tar 文件无需接触磁盘。

缺点是如果连接断开则不容易恢复。

Tar 也有一个--exclude选项（但没有--include），因此，如有必要，您可以以类似的方式并行化流。同样，您可能应该使用 rsync 来验证传输。

另外：“TCP 的本质”是不是问题就在这里。TCP 使用滑动窗口方案，在任何正常延迟下都应该使链路饱和，并且旋钮如果没有的话。

然而，rsync 的本质是，它必须在传输每个文件之前来回进行一些沟通，这里延迟会受到影响（尽管实现使用流水线来最小化这一点）。

如果您的链接没有饱和，那么首先要尝试的是将 rsync 从方程式中移除（scp一个足够大的文件就可以了）。如果这仍然不起作用，那么请检查您的 CPU 使用率：压缩和加密可能是瓶颈。如果通过 Netcat（或老式 FTP）传输纯数据无法做到这一点，那么您可能需要调整 TCP。此外，使用检查数据包丢失ping，因为这会真正搞砸 TCP。最后，可能只是链中最慢的链接不是您的。

Answer