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，他们经历了三个阶段：

1. NFS共享，挂一个盘阵，APP服务器通过NFS读写
2. 加一个中间层Cachr：eventHttp + memcached(lighttpd + mod_memcache实现同样的功能)，后端还是通过NFS连盘阵
3. 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所有