我目前正在寻找可以优化网络带宽使用的解决方案。
设想：服务器有一个文件。客户端通过 REST API 下载该文件。客户端进行一些更改，并通过 REST 将更改后的文件上传回服务器。服务器将用上传的文件替换原始文件。
可能的方法 我想到两种可能的方法。
1- 局部差异在进行任何更改之前，客户端将复制原始文件。进行更改后，客户端将使用 BSDiff 或 XDelta 等算法通过比较原始文件和更改后的文件来提取更改。然后这些更改将发送到服务器。服务器将对原始文件应用差异。
2- 使用 R-Sync向服务器发出 REST 调用并请求初始滚动校验和和 MD5 哈希值。然后根据响应生成差异并将其发布到服务器。服务器将合并更改。
我做了一些粗略的测试，发现 BSDiff 是最有效的解决方案（就差异大小而言 - 这是主要的优化目标）。它生成尽可能小的差异，但占用大量内存，因此无法在客户端使用大文件。另一方面，我尝试过的 X-Delta 和其他二进制差异工具在生成的差异大小方面效果并不好。本地差异还存在占用额外磁盘空间的缺点，因为要保留原始文件的副本。对于大文件，这可能是一个问题。
BSDiff 的内存问题使得 R-Sync 成为最合适的选择（因为其他工具在查找差异方面效率不高）。所以我决定选择 R-Sync。
R-Sync 分为两个步骤。首先，它根据文件获取签名，然后根据之前发送的签名发回数据。我计划通过在对原始文件进行任何更改之前在客户端保留原始文件的签名来进一步优化 R-Sync。这将消除客户端在上传时请求服务器计算和发送签名的需要。客户端只需在客户端想要上传文件时根据已计算的签名将数据发送到服务器即可。
问题我知道这个问题有点奇怪，所以我问了一个问题在真正在这里提问之前。我只是想知道是否有更好的替代方案来解决此类问题？我想确认我的方法只是为了确保我走在正确的道路上并且没有遗漏任何重要的事情。
答案1
我认为您的决定rsync是最好的。它具有成本效益、准确且经过深思熟虑。请记住使用--strict选项，md5sum否则您可能会遇到麻烦。您可能需要考虑跳过对大文件的一些检查，因为它只会消耗资源并产生相同的结果。想象一下，您比较两个 2GB 文件 - 删除旧文件、复制新文件并更新哈希值和校验和要比创建新哈希值、将其与旧文件进行比较然后合并更改容易得多。对于小文件来说没有区别。
另一个想法是只diff在哈希上运行，然后部分传输文件 - rsync--checksum和--update是--inplace你的朋友。
为了进一步优化网络带宽使用，您可以考虑--compress和--bwlimit=选择。
我不知道您需要多久传输一次这些文件，同步频率是多少。如果太频繁，最好设置齐奏. 更多信息请见Linux 杂志。
祝你好运！
答案2
这基本上超出了我的理解范围 - 特别是对于二进制文件，但普通的旧 rsync 默认不是只将更改传输到非本地目的地吗？（如果不是，它有一个 --nowhole-files 选项。）
如果是这样，它将为您完成所有工作。
如果您需要更多详细信息，请发帖至[电子邮件保护]非常乐于助人的 rsync 专家聚集的地方。您可以在以下网址订阅https://lists.samba.org/mailman/listinfo/rsync 。
对于这样的问题，如果您能说明您使用的操作系统和版本以及相关程序的版本，将会很有帮助。我从未听说过 R-Sync，但我一直在 Linux 上使用 rsync。
我不确定，但我相信我已经看到过在 Windows 上的 cygwin 下运行 rsync 的参考（如果您的环境是 Windows 的话）。
该论坛专门处理有关 Windows 和 Linux 的问题，因此在这里指定您的环境就显得更为重要。
也可以看看https://en.wikipedia.org/wiki/Rsync 它涵盖了 rsync 本身以及您可能会觉得有用的其他实用程序（例如 rdiff）。