在我工作的公司，我们有一个叫做“播放列表”的东西，它们是小文件，每个文件大小为100-300字节。 大概有一百万 其中约有10万人每小时换一次。 这些播放列表需要每小时上传到不同大陆的其他10台远程服务器，理想情况下需要在2分钟内快速完成。 在主服务器上删除的文件在所有副本上也被删除，这一点非常重要。 我们目前使用Linux作为基础设施。
我正在考虑尝试使用-W选项rsync来复制整个文件，而无需比较内容。 我还没有尝试过，但也许有更多的经验与rsync的人可以告诉我，如果这是一个可行的select？
还有什么其他的select值得考虑？
更新：我select了lsyncd选项作为答案，但只是因为它是最受欢迎的。 其他build议的替代方法也是有效的。
由于即时更新也是可以接受的，您可以使用lsyncd 。
它监视目录（inotify）并将rsync更改为从属。
在启动时，它会做一个完整的rsync ，这将需要一些时间，但之后，只有变化传输。
目录的recursion观察是可能的，如果从属服务器closures，同步将被重试，直到它返回。
如果这是全部在一个目录（或静态目录列表），你也可以使用incron 。
缺点是它不允许recursion观察文件夹，你需要自己实现同步function。
考虑使用分布式文件系统，如GlusterFS 。 考虑到复制和并行性的devise，GlusterFS可能比使用inotify和rsync ad-hoc解决scheme更加顺畅地扩展到10台服务器。
对于这个特定的用例，可以构build一个10台服务器的10个副本GlusterFS卷（即每个服务器1个副本/块），以便每个副本将成为该卷中每个其他副本的精确镜像。 GlusterFS会自动将文件系统更新传播到所有副本。
每个位置的客户端都会联系他们的本地服务器，所以读取文件的速度会很快。 关键问题是写延迟是否可以保持在可接受的低水平。 唯一的答案就是尝试一下。
我怀疑rsync会以正常的方式工作，因为扫描一百万个文件并将其与远程系统比较10次需要很长时间。 我会尝试实现一个类似inotify的系统，它保存已修改文件的列表并将它们推送到远程服务器（如果这些更改没有以其他方式被logging）。 然后，您可以使用此列表快速识别需要传输的文件 – 甚至可以使用rsync（或更好的10个并行实例）。
编辑：有了一点工作，你甚至可以使用这种inotify /日志观察的方法，修改发生后尽快复制文件。
更多的select：
这似乎是MongoDB和GridFS的理想故事书用例。 由于文件相对较小，单独使用MongoDB应该足够了，尽pipe使用GridFS API可能会很方便。
MongoDB是一个nosql数据库，GridFS是一个基于它的文件存储。 MongoDB有很多内置的复制和分片选项，所以它在你的用例中应该很好地扩展。
在你的情况下，你可能会开始一个副本集，其中包括位于主数据中心的主节点（可能是第二个副本，以防在同一位置进行故障切换）以及分布在世界各地的十个“奴隶”。 然后，执行加载testing来检查写入性能是否足够，并检查到节点的复制时间。 如果你需要更多的性能，你可以把设置变成分片（主要是把写入负载分配给更多的服务器）。 MongoDB的devise是用“便宜”的硬件扩大规模，所以你可以投入一批廉价的服务器来提高性能。
我将使用一个S3后端，然后将其安装在我需要的所有服务器上 – 这样，每个人都可以即时同步
似乎还没有提到的选项是将所有文件归档到一个压缩文件中。 这将显着减less总体大小，并消除处理数百万个人文件所带来的所有开销。 通过在一个大的更新中replace整个文件集，您也可以放心，删除的副本上的文件被删除。
不利的一面是，你正在不必要地传输多个文件。 这可能会或可能不会由于压缩而减小大小。 我也不知道压缩那么多文件需要多长时间。