可以有效地与远程服务器同步100万个文件的选项？

在我为之工作的一家公司中，我们有一个称为“播放列表”的东西，它们是每个〜100-300字节的小文件。大约有一百万。每小时大约有100,000个被更改。这些播放列表需要每小时上传到不同大洲的其他10个远程服务器，并且理想情况下，播放列表必须在2分钟内快速完成。在主副本上删除的文件也必须在所有副本上删除，这一点非常重要。目前，我们将Linux用于基础架构。

我正在考虑尝试使用带有-W选项的rsync复制整个文件而不比较内容。我还没有尝试过，但是也许有更多rsync经验的人可以告诉我这是否可行？

还有哪些其他选项值得考虑？

更新：我选择了lsyncd选项作为答案，但这仅仅是因为它是最受欢迎的选项。其他建议的替代方案也以其自己的方式有效。

由于即时更新也是可以接受的，因此可以使用lsyncd。
它监视目录（intify），并将其rsync更改为从属。
在启动时，它将完成一个full rsync，因此将花费一些时间，但是之后仅传输更改。
可以递归监视目录，如果从属服务器关闭，则将重试同步，直到同步回来。

如果所有内容都在一个目录（或目录的静态列表）中，则也可以使用incron。
缺点是它不允许递归监视文件夹，并且您需要自己实现同步功能。

考虑使用分布式文件系统，例如GlusterFS。考虑到复制和并行性，GlusterFS可以扩展多达10台服务器，这比涉及inotify和的即席解决方案要平滑得多rsync。

对于此特定用例，可以构建一个由10个服务器组成的10台服务器的GlusterFS卷，其中包含10个副本（即每个服务器1个副本/块），这样每个副本将成为该卷中每个其他副本的精确镜像。GlusterFS会自动将文件系统更新传播到所有副本。

每个位置的客户端都将联系其本地服务器，因此对文件的读取访问将很快。关键问题是写延迟是否可以保持在可接受的低水平。回答该问题的唯一方法是尝试一下。

我怀疑rsync这样做是否可以正常进行，因为扫描一百万个文件并将其与远程系统进行10次比较将花费很长时间。我会尝试使用类似的系统来实现，该系统inotify会保留已修改文件的列表，并将它们推送到远程服务器（如果这些更改无论如何都不会以其他方式记录下来）。然后，您可以使用此列表快速识别需要传输的文件-甚至可以使用rsync（或更好的10个并行实例）。

编辑：经过一点工作，您甚至可以在修改发生后立即使用这种inotify / log watch方法来复制文件。

其他一些选择：

• 将作业插入RabbitMQ或Gearman，以在每次在主服务器上删除或添加文件时异步关闭并删除（或添加）所有远程服务器上的相同文件。
• 将文件存储在数据库中，并使用复制来使远程服务器保持同步。
• 如果您具有ZFS ，则可以使用 ZFS复制。
• 某些SAN具有文件复制功能。我不知道是否可以在Internet上使用它。

对于MongoDB以及GridFS来说，这似乎是一个理想的故事书用例。由于文件相对较小，因此尽管使用GridFS API可能很方便，但仅MongoDB就足够了。

MongoDB是一个nosql数据库，而GridFS是在其之上的文件存储版本。MongoDB有很多内置的复制和分片选项，因此在您的用例中应该可以很好地扩展。

在您的情况下，您可能会从一个副本集开始，该副本集由位于主数据中心中的主副本（如果要在同一位置进行故障转移，则可能是第二个副本副本）和分布在世界各地的十个“从属副本”组成。然后进行负载测试，以检查写性能是否足够，并检查到节点的复制时间。如果需要更高的性能，可以将设置变成分片的设置（主要是将写负载分配给更多服务器）。MongoDB的设计旨在通过“廉价”硬件扩展大型设置，因此您可以投入一批廉价的服务器来提高性能。

我将使用S3后端，然后将其安装在我需要的所有服务器上-这样，每个人无论如何都会立即同步

似乎尚未提及的一个选项是将所有文件归档到一个压缩文件中。这将显着减小总大小，并消除处理数百万个单独文件所产生的所有开销。通过在一个大更新中替换整个文件集，您还可以放心，已删除的文件将在副本上被删除。

不利之处当然是您不必要地传输了许多文件。由于压缩，减小的大小可能会平衡，也可能无法平衡。我也不知道压缩那么多文件要花多长时间。