当前比较适用的海量小文件系统架构方案

现在的网站越做越大了，存储的东西越来越多，如何解决这些文件存储也成了新的难题。如果把这些文件都完全采用大硬盘存储来解决，并不是一个好主意，因为数据量越大风险就越高，虽然文件能存得下，但是故障率相应会较高，另外重建耗费时间也比较长。所以最好的办法是尽可能考虑分布式存储，把文件想办法利用网络分散到多个机器上。

从我所了解的存储结构来看，分布式存储大致可以分为几种：

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，缺点是使用的机器就会成倍增加；亦可再用一级代理服务器，缺点是会牺牲性能。采用目录的话，因为本身就用到了代理服务器，所以只要存储得当，实现比较容易。

--------------------------------------------------------------------------------