图片服务一般数据容量较大,并且访问也频繁,鉴于此,图片服务就会有两种问题,一是存储问题,二是访问量问题。nginx
存储问题就是硬 盘容量问题,花钱买硬盘就能够了,看似简单,但着实也是最苦的问题。按目前探索来看,最好的方式是:在任什么时候刻遇到硬盘空间不够时,买颗硬盘插上,最多改 改配置,就能马上利用;另外,硬盘要能充分利用,否则图片存储量大再加上备份,很恐怖,最好是每颗硬盘都用上100%的空间。服务器
访问量 也是个大问题,若是服务不容许防盗链,那么访问量会引发带宽、服务器压力等问题,有钱的话直接扔CDN,没钱或者有更多的钱,就本身作吧。根据垣古不变的 真理“越老的图,访问量也相对较少”这一点,分红两大部分,一边处理最新的图片,一边处理老旧的图片。最新的图片访问量大,但存储量较少;老图片访问量 低,但存储量大。架构
大概分析完了,开始制定方案。负载均衡
1、拟定一个存储目录规则:ui
在现有的/a/b/abcde.jpg这样的hash方式下多加一个日期的目录变成:/200810/16/a/b/abcde.jpg或者/2008/10/16/a/b/abcde.jpg。按日期制定这个目录规则后,就能够按年月来拆机器了。代理
2、分机器,分硬盘图片
按以前的计划,分红两个组,一组服务器用lvs作负载均衡负责新图片;另外一组服务器作旧图片访问和备份。新图机器找几台好点的服务器,SCSI硬盘;旧 图机器没太大要求,PC机就行,找够硬盘就能够,如今IDE的1T硬盘也不太贵,最好再搭个raid就省事了,最主要是这些机器要多。hash
说明一下:图片存储
使用这个架构的话,硬盘不够的话,加硬盘就能够了。若是图片量实在太大,主服务器连一年的数据都装不下,那能够用启用月份来划分;若是一个月都装不下了,那也太夸张了,那就启用日期吧;若是一天的数据都装不下,那就使用小时,依次类推。配置