在我工作的公司,我们有一个叫做“播放列表”的东西,它们是小文件,每个文件大小为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整个文件集,您也可以放心,删除的副本上的文件被删除。
不利的一面是,你正在不必要地传输多个文件。 这可能会或可能不会由于压缩而减小大小。 我也不知道压缩那么多文件需要多长时间。