Web2.0网站，数据内容以几何级数增长，尤其是那些小文件，几K～几百K不等，数量巨多，传统的文件系统处理起来很是吃力，很多网站在scaling的过程中都遇到了这样的问题：磁盘IO过高；备份困难；单点问题，容量和读写无法水平扩展，还存在故障的可能。

    YouTube也碰到这样的问题，每一个视频有4个缩微图，这样的话缩微图数量是视频数量的四倍，想象一下YouTube有多少视频，看一下他们遇到的问题：

大量的磁盘寻址，在操作系统层面出现inodes cache和page cache的问题单个目录文件数限制，尤其是Ext3文件系统，采用目录分级的做法，最新的Linux Kernel 2.6优化了Ext3文件系统，单目录能存储的文件数提高了100倍，但是把所有的文件存一个目录不是一个好的方法高RPS（requests per second每秒请求数），因为一个页面可能要显示60个缩微图高负载下Apache性能差Apache前面加一层Squid，能抗一会，但负载上来之后，性能下降厉害，由300RPS降到20RPS尝试lighttpd，但是lighttpd是单线程，多线程的话也有问题，线程之间缓存不能共享加一台服务器的话需要24小时，因为文件数太多了存在“冷却”的问题，重启服务器后需要6～10个小时才能缓存好

    YouTube的解决方案是Google的BigTable，一般人没戏。（原文参见：http://www.hfadeel.com/Blog/?p=127）

    Facebook也遇到了同样的问题，他们的方案参见：http://www.dbanotes.net/arch/facebook_photos_arch.html，他们经历了三个阶段：

NFS共享，挂一个盘阵，APP服务器通过NFS读写加一个中间层Cachr：eventHttp + memcached(lighttpd + mod_memcache实现同样的功能)，后端还是通过NFS连盘阵Haystacks，详细的去读这里（E文）。

    对于一般的网站来说，实用的方案有哪些呢？

    一、NFS共享

    是的，这个有很多问题，但实施成本低，很多公司都在用（我们也在用），在不是那么多文件，不是那么高并发的情况下还是很不错的，设置Hash目录，不要让一个目录下文件数过多，对于一般的网站来说足够用了。

    备份确实是一个问题，如果不是海量的话，根据文件更新时间每天增量备份＋周期性的全量备份应该可以。

    二、文件存数据库

    真有人这么做，手机之家用MySQL建了256个表来存储超过1T的文件，前端加一个多级缓存（具体未知，也许就是memcached也许还是文件），数据库做数据备份用，他们用起来觉得还不错。

    或者觉得MySQL太重，试试key->value的数据库，比如BDB，Tokyo Cabinet等。

    三、分布式文件系统

    开源的很多，好看簿用的是MogileFS，与memcached师出同门。傲游用MFS来存储用户的收藏夹文件，详细文章参见：分布式文件系统MFS(moosefs)实现存储共享(一) 、(二)，据说数百万轻松处理。

    分布式文件系统好处是可以均衡读写压力，数据可靠性大大增加，某个数据节点挂了也没事。

    还不行？自己DIY一个去吧，豆瓣就这么做的，TokyoCabinet做为底层存储，封装了一个memcached协议接口（与Tokyo Tyrant何异？），一致性哈希，应用程序根据哈希规则在node中读写数据:

    DoubanFS结构图，版权由charlee所有

建议继续学习：

1. HFile存储格式    (阅读：14538)
2. 我对技术方向的一些反思    (阅读：9872)
3. 淘宝图片存储架构    (阅读：9837)
4. 其实，文件也可以truncate    (阅读：7397)
5. HBase技术介绍    (阅读：6760)
6. 存储基础知识之——硬盘接口简述    (阅读：6157)
7. 在perl中连接和使用sqlite做数据存储    (阅读：5058)
8. 如果用户在5分钟内重复上线，就给他发警告，问如何设计？    (阅读：4872)
9. 关于Linux的文件系统cache    (阅读：4791)
10. Redis新的存储模式diskstore    (阅读：4409)