需要访问者能够上传文件.这些文件的大小通常为300-700KB,我们预计其中有100万个.但是,这会带来一个明显的问题：如果用户将文件上传到处理其请求的服务器,我们如何保持所有服务器同步？
延迟应该是最小的,因此在设定的时间表上使用像rsync这样的东西并不是一个真正的选择.应该没有单点故障,因此NFS不适合,除非它与DRBD结合以创建故障转移NFS服务器.
我已经研究过共享/集群文件系统(GlusterFS,MogileFS,OCFS2和GFS),但没有这方面的经验,所以我不确定它们在生产环境中的性能和可靠性如何.
我欢迎任何关于如何最好地解决这个问题的建议.
非常感谢
解决方法
GlusterFS听起来更像你正在寻找的东西.它会有一些独特的怪癖,即在尚未拥有它的节点上请求的文件,元数据查找说它存在,它从一个复制节点传输然后提供.在节点上首次请求将有一些延迟取决于文件大小.
OpenAFS也是另一种可能性.您有共享存储,每个本地资源都有一个最近使用过的项目的本地池.如果存储引擎发生故障,您的本地资源池仍可用.
Hadoop的HDFS是另一种“有效”的选择.设置有点复杂,但也符合您的要求.使用分布式文件系统时,您将拥有大量重复内容.
另一种脏方法是在每个Web前端上运行缓存,从单个机器上提取静态/上传内容,并在每个前端使用Varnish来维护单个副本的ram缓存版本.如果您的单台机器出现故障,Varnish将缓存现有项目,直到宽限期,新项目将丢失.
其中大部分将基于您需要的后端的可靠性.本地计算机是复制节点的分布式文件系统可能会有速度优势,因为它们不涉及网络操作来获取数据,但是,由于gigE和10G卡很便宜,您可能不会遇到明显的延迟.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。