图片存储：随时间增加新域名进行扩容的办法
图片服务的特点就是：不修改，少量新增/极少删除，存储量大，需要尽量避免迁移和复制；旧的集群锁定后：对于原来的文件基本上就只删不增了；虽然目前有很多开源的分布式文件系统，但是目前比较便宜的解决方法还是本地硬盘服务器不断一组一组的增加，相互备份的一组服务器作为基础存储，然后前端使用缓存服务器；通过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年底；
《构建可扩展的Web站点》上没有提到这个策略，猜测Flickr应该是不断在启用新的服务器集群，当地一个集群用到90%的时候，开始启用下一个集群。一个用户的所有图片地址则存储在数据库中：记录会包含当时的存储所在的集群：这个策略可以学习一下；
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
而前端则通过前端目录规则，将请求rewrite访问后台不同的存储服务器上：
foo.example.com/200711/ >> 200711.foo.example.com
foo.example.com/200712/ >> 200712.foo.example.com
...
foo.example.com/200811/ >> 200811.foo.example.com
这样就简单的实现了图片存储随时间增加而扩展的，每隔一定时间将上传服务器指向到新的服务器集群；
