现在的网站越来越大，存储的东西越来越多。如何解决这些文件存储问题成为一个新的问题。将所有这些文件存储在一个大硬盘中并不是一个好主意，因为数据量越大，风险就越高。虽然可以保存文件，但是失败率会比较高，重建需要很长时间。所以最好的办法就是尽可能考虑分布式存储，尽量利用网络把文件分发到多台机器上。
从我了解的存储结构来看，分布式存储大致可以分为几种类型：
1.像googlefs这样的分布式文件系统
目前因为googlefs没有开源，所以互联网上所有的分布式文件系统都是用google的方案实现的。这个方案的好处是可用性比较高，基本上所有基于硬盘的应用都可以处理，可用范围比较广。看过一些gfs，gfs2，ocfs2，FastDFS，MogileFS的相关介绍，有一些大概的了解。
首先，文件少会带来很多问题；不过目前这些都不能称之为稳定版，如果有，估计也有一部分是付费版。因为磁盘存储很重要，所以建议目前不要轻易把这些东西部署到重要的地方。如果真的要用，最好做一个全面的测试，确保其功能完全能满足需要；然后尽量在传统文件系统中进行完整备份，避免丢失。
另一个可以提的是memcached，它实现了内存的分布式共享，稳定性似乎比上面的分布式文件系统更稳定。但是，它是完全基于记忆的。如果数据量不是很大，可以试试。
2.手动使用文件路径进行分散存储。
这种结构通常用在web静态文件中，所以以这种情况为例。
如果这些文件的数量很大，可以通过分散文件路径，将文件的访问权限分配给特定的一台或多台服务器。例如：
1)采用域名去中心化策略
例如，a.xxx.com/b.xxx.com.用于区分一系列标记为A或B的文件，当存储这些文件时，它们仍然根据标记存储在A或B的服务器上。在该策略中，区分机器的任务被分配给dns服务器，这将更容易扩展容量。这就需要在web项目前期就规划好这些东西，后期转域名策略的成本相对较高甚至无法实现。
2)采用目录去中心化策略。
如果域名开头没有规划域名策略，那么可以使用代理服务器进行目录级划分。比如在存储大量文件的时候，因为文件系统的限制和效率问题，按照一定的规则划分了很多层次的目录，根据这些目录拆分机器并不难。这种架构的问题在于代理服务器的性能和可靠性，需要下一点功夫。
对于以上两种方案，要自己制定策略，实现分散同步传输。传输一般可分为两种方法：推和抓。对于同步，可以采用日志同步(记录要同步的数据，通过日志记录传输相应的文件)、比较同步(使用rsync等同步软件)或即时同步(有任何新的变化立即传输)；另外，要消除单点故障，先找一个策略把文件存储在多个节点上，比如a.xxx.com或者目录A的文件也存储在节点B和C上；然后，使用故障排除技术(lvs或nginx等)即可解决问题。)在环境中。比如采用域名，可以采用lvs，但是使用的机器数量会成倍增加。也可以复用一级代理服务器，但缺点是会牺牲性能。如果采用目录，只要存储得当，很容易实现，因为使用的是代理服务器本身。
