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结构图