如何高效地将 100 万个文件与远程服务器同步？

Question

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

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

还有哪些选择值得考虑？

更新：我选择 lsyncd 选项作为答案，只是因为它最受欢迎。其他建议的替代方案也各有千秋。

Answer 1

由于即时更新也是可以接受的，您可以使用同步。
它监视目录（inotify）并将rsync更改传输到从属服务器。
启动时，它将执行完整的同步rsync，因此需要一些时间，但之后只会传输更改。
可以递归监视目录，如果从属服务器关闭，将重试同步，直到它恢复。

如果所有这些都在单个目录中（或静态目录列表），您也可以使用因克龙。
缺点是它不允许递归监视文件夹，您需要自己实现同步功能。

Answer 2

考虑使用分布式文件系统，例如集群文件系统. GlusterFS 在设计时充分考虑了复制和并行性，因此可以比涉及 inotify 和 的临时解决方案更加顺利地扩展到 10 台服务器rsync。

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

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

Answer 3

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

编辑：只需一点点工作，您甚至可以使用此 inotify/log watch 方法在修改发生时立即复制文件。

Answer 4

这似乎是MongoDB有可能网格文件系统由于文件相对较小，单独使用 MongoDB 就足够了，尽管使用 GridFS API 可能会更方便。

MongoDB 是一个 NoSQL 数据库，GridFS 是一个建立在其上的文件存储。MongoDB 有很多内置选项复制和分片，因此它应该能够很好地适应您的使用情况。

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