现在网站越做越大，存储的东西越来越多。如何存储这些文件成了一个新问题。把这些文件都存储在一个大硬盘上并不是一个好主意，因为数据量越大，风险就越高。尽管文件可以被存储，
但是失败率会比较高，重建需要很长时间。所以最好的办法就是尽可能考虑分布式存储，尽量利用网络把文件分发到多台机器上。
从我了解的存储结构来看，分布式存储大致可以分为几种类型：
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。
缺点是用的机器数量会成倍增加；也可以使用一级代理服务器，但缺点是会牺牲性能。如果使用目录的话，因为使用的是代理服务器本身，只要存储得当，比较容易实现。
