车东[Blog^2]

图片服务的特点就是：不修改，少量新增/极少删除，存储量大，需要尽量避免迁移和复制；旧的集群锁定后：对于原来的文件基本上就只删不增了；虽然目前有很多开源的分布式文件系统，但是目前比较便宜的解决方法还是本地硬盘服务器不断一组一组的增加，相互备份的一组服务器作为基础存储，然后前端使用缓存服务器；通过LVS或者CDN进行负载/分布的均衡。

目前一台服务器配上T的存储也相对比较便宜；关键是如何尽量避免使用NFS进行使用；目前我们选择的办法是：图片服务器一组使用2台，一组服务器之间使用NFS相互mount用于备份；另外有上传文件服务器会NFS访问；对外服务文件使用Web服务器负载均衡。而在2台服务器上，会给予基于ID将用户的图片进行存储，存储的分布化会遇到一个问题：固定存储空间随着时间增加再次达到系统的空间/负载的瓶颈。观察了一下Flickr的图片存储地址：好像是在定期启用新的集群，各个时期的域名分布如下：

http://farm1.static.flickr.com 2006年中以前；
http://farm2.static.flickr.com 2006年底；
http://farm3.static.flickr.com 2007年底；
http://farm4.static.flickr.com 2008年底；

user_foo - farm1.static....../20060124_003.jpg
\ farm1.static....../20060324_005.jpg
\ farm1.static....../20060824_021.jpg
\ farm2.static....../20070124_006.jpg
\ farm3.static....../20080124_002.jpg
\ farm4.static....../20081124_001.jpg

另外如果希望前端存储使用的域名一直保持不变，通过目录规则进行rewrite的方式也是可以的，比如：将要发布的内容，后端按时间建立一个域名进行存储；

200711.foo.example.com
200712.foo.example.com
200801.foo.example.com
...
200811.foo.example.com

foo.example.com/200711/ >> 200711.foo.example.com
foo.example.com/200712/ >> 200712.foo.example.com
...
foo.example.com/200811/ >> 200811.foo.example.com

这样就简单的实现了图片存储随时间增加而扩展的，每隔一定时间将上传服务器指向到新的服务器集群；