即使我完全意识到这个问题的版本已经被问到googol的次数，我会尽量不重复。
我有很多文件集（有些文件很小，但有些很大，比如〜10-20GB）。 我有多台服务器，每台服务器可以承载一组或多组这些文件。 当然，一台服务器可以承载总数的50％，另外50％可以承载另外几台。
你可以把集合视为大型媒体文件的集合，真正的大型图像库，完整的应用程序，无论如何，只要集合中有大文件，它就无关紧要。
服务器可以在任何时间点更新其集合的副本（通过用完全新的文件replace集合中的文件，或者通过向一些文件应用修补，这将导致具有几乎相同的文件，只有细微的差别）。
另一方面，我有许多客户，他们应该能够从服务器获得任何给定的集合（或多个集合），并且随时随地将他们的集合的副本与服务器上的集合保持一致使用集合。
我考虑的工具如下：
- rsync – 同步许多中小型文件非常棒，但是在同步大型文件时不太理想，因为它使用的是在两侧读取整个文件的algorithm，以确定文件是否应该被复制。 当文件第一次被复制，或者当文件被完全改变时，这是可以的，但是当10GB文件只有1％被改变时，并不是那么好。
- SVN – 在发现差异和转移只有那些三angular洲时非常好，但是我不确定在磁盘使用方面有多么的优化（在客户端和服务器上，一旦设置存储在仓库？）。
- 洪stream – 这一个可能是可行的，分布明智的。 例如，为服务器上的每个集合创build一个种子，在那里开始种子，并且接收这些集合的客户端也继续向其他客户端发起种子，从而将负载分布到每台持有集合副本的计算机上。 但是，我不确定它是否能够以某种方式分配差异，一旦在服务器上设置得到改变…是否需要为每个更改创build新的洪stream？ 另外，我不知道Torrent在本地networking中的行为如何，速度方面（能够最大限度地在一个服务器和一个客户端之间传输文件，限制networking速度，还是增加了一些严重的协议开销？networking拥塞？）
- 定制解决scheme 那么在这里添加的东西不多，但是最有可能的是重新发明轮子，如果我只知道这一点，那么现有的解决scheme很可能适合我的需求。
所以，问题是：什么分配/同步方法（公用设施，方法）最适合我的情况？
如果您可以安全地假设所有客户端都将具有一致的版本，则可以使用现成的二进制补丁工具并滚动您自己的解决scheme，将差异推送给客户端并应用它们。 但是，如果客户端版本不一致，则必须读取客户端上的文件以确定哪些差异需要发送（基本上是rsync问题）。 但是，如果客户端是一致的，那么只需计算一次差异并发送出去即可。
这听起来像你正在寻找像多播rsync实现的东西。 我从来没有使用过这个工具，但是值得一看。 看起来他们现在只是针对Linux和Unix操作系统。
最后，我select了BitTorrent。 这是为什么。
- 速度很快：它完全饱和了服务器的上行链路（不过，由于小数据量的疯狂，它确实会减慢相关计算机上的networking速度，这可以通过禁用UDP数据包来进行一些优化）。
- 在任何一组文件上分配任何一组更改都是非常好的和快速的（BT协议的最小数据单元是一个“块”，其大小从4KB到4MB不等，每个文件被分割成块，块被校验和，然后只传输不同的文件，无论文件是KB还是GB文件 – 这个过程非常快。
- 它是完全分布式的：您可以从多个不同的源服务器上托pipe多组文件，并且让客户端检索文件，而不pipe它们被存储在何处（我知道这是一种模拟点）。
- 服务器将其内容副本上传到networking后，服务器负载急剧下降，新部署的客户端接收最新的集合的时间大大减less，因为集合是从整个计算机networking接收的，而不是单一的集中式服务器。
- 它可以用在小的安装只有正确configuration的uTorrent客户端程序，它可以用来创build.torrent的，跟踪种子/同行，并在客户端计算机上接收数据。
关于我遇到的唯一两个缺点：
- 为大数据集创build洪stream可能需要很多时间（很多：5-10分钟），而.torrent被创build（整个集合被读取，拆分成碎片，校验和），如果集合不可用，这会进一步减慢在本地，而是从networking取而代之。 而且，如果想要在一个大集合上分配任意数量的变化（每台计算机 – 服务器和所有客户机）都需要执行校验和部分，那么需要相同的时间量，正如我所说，这个部分可能会很长。 （我必须在这里注意到，就我而言，变化是非常小的，将GB的数据复制到几MB的变化数据周围是不切实际的，所以这是一个非常可以接受的平衡。）
- 初始播种机可能需要一段时间才能达到全速，所以如果需要在less于5台计算机之间简单地复制文件，这种方法是不适合的（但实际上， 3台电脑）。
你走了，我希望我帮助一个面临同样困境的人。
您可以尝试cachingnetworking文件系统：
它们都在本地caching读取和写入，因此如果您有足够的本地caching空间，则不会受networking性能的影响。
您可以使用Windows Storage Server 2008，它与来自不同提供商的NAS设备一起销售，但它是非常好的和有效的，单实例存储以及为您节省几GB。 然后你可以有一个专用的设备来处理这些大文件。
这些NAS中大部分都带有双NIC，您甚至可以使用四端口NIC，所以如果您拥有千兆位或更高的LAN基础设施，则可以将这些端口捆绑/组合，以提供更高的吞吐量。
把更多的内存，你应该很好去，www.broadberry.com http://www.broadberry.com/nasstorage_servers.html
戴尔也销售Window Storage Server，如果您以后也有通过iscsi的话，也可以利用存储来获得具有iscsi的存储服务器。
希望有所帮助