尽管我完全清楚这个问题已经被问过很多次了古戈尔次数多了，我就会尽量不再重复。
我有许多文件集（有些文件很小，但有些很大，大约 10-20GB）。我有多台服务器，每台服务器可以托管一个或多个文件集。当然，一台服务器可以托管总文件集的 50%，另外 50% 可以托管其他数量的文件集。
你可以想到放至于大型媒体文件的集合、真正大型的图像库、完整的应用程序等等，其实都不重要，只要集合中包含大型文件即可。
服务器可以在任何时间点更新其集合的副本（或者用全新的文件替换集合中的文件，或者对某些文件应用补丁，这将导致几乎相同的文件只有细微的差别）。
另一方面，我有很多客户，他们应该能够从服务器获取任何给定的集合（或多个集合），并且在想要使用该集合时，让他们的集合副本与服务器上的集合保持最新（同步）。
我考虑过的工具如下：
- rsync——它非常适合同步许多中小型文件，但在同步大型文件时不太理想，因为它使用从两端读取整个文件的算法来确定是否应复制文件。当文件第一次需要复制或文件完全更改时，这种方法是可行的，但当 10GB 文件中只有 1% 发生更改时，这种方法就不太可行了。
- SVN——在查找差异并仅传输这些差异方面，它非常有用，但我不太确定它在磁盘使用方面是否优化（由于一次集合存储在存储库中，整个集合在客户端和服务器上的大小是否会增加一倍？）。
- Torrent——从分发角度来看，这种方法是可行的。例如，为服务器上的每个集合创建一个 torrent，开始在那里播种，接收这些集合的客户端也会继续播种到其他客户端，从而将负载分布到拥有该集合副本的每台计算机上。但是，我不确定一旦服务器上的集合发生变化，它是否能够以某种方式分配差异……是否需要为每次更改创建新的 torrent？另外，我不知道 torrent 在本地网络中的速度如何（它能否在网络受限的情况下以最大速度在一台服务器和一台客户端之间传输文件。或者它会增加一些严重的协议开销？网络拥塞怎么办？）
- 定制解决方案。好吧，这里没什么可补充的，但它很可能是重新发明轮子，而且如果我意识到的话，一些现有的解决方案很可能适合我的需求。
因此，问题是：哪种分发/同步方法（实用程序、方法）最适合我的情况？
答案1
在您列出的解决方案中，SVN 看起来最有希望。您需要在存储库中存储至少 1 个副本，因此您将使用最多 2 倍的空间（如果您有 2 个工作副本，则为 3 倍）。
在当今时代，硬盘空间（通常）很便宜，所以我不认为空间要求会造成太大的负担，特别是与尝试制定自己的定制解决方案相比。
您可能还想了解MS 同步框架，由 SyncToy 使用。