现在很多中小网站都允许用户上传图片,如果前期没有很好的规划,那么随着图片文件的增多,无论是管理还是性能上都带来很多问题。就自己的一点理解纯属理论,没经验证,谨慎参考。
在当前的经济形势下,遵循“少花钱、多办事”的原则,采用纯Open Source的方案,不增加软件投入。
图片的存储硬件
把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备,那么简单的很;
如果上述条件不具备,只想在普通的硬盘上存储,首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的,实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ,怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑,选择合适大小的 inode size ,在空间和速度上做取舍,同时防患于未然,注意单个文件系统下文件个数别达到极限。
图片存储的技巧
图片服务器当前用年份来划分,每年增加两台服务器,亦可是加两块硬盘;因为旧数据2006和2007年的数据基本上是没有变化的,图片不存在修改,如果细心定制,那么旧图片服务器的硬盘99%塞满是可以的,旧数据的容量基本上不会大幅增长,小小预留1-2G空间就可以了.
单独的图片服务器域名
比如yahoo.com 图片服务器用了 yimg.com 的域名,这样可以减少上行的头信息,应用服务器也不用检查权限.
单独多个图片服务器
无论从管理上,还是从性能上看,只要有可能,尽量部署独立的图片服务器。在 Web 服务器上就可以有针对性的进行配置优化。比如在选择web服务器时,只考虑处理图片的效率.
图片共享
如果不想在几台机器间同步所有图片,只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题,以及 NFS 特定的传输速度。
采用操作系统层分布式文件系统本身的同步功能
采用应用层分布式文件系统同步方案:FastDFS、MogileFS、Hadoop HDFS
http服务器的选择
采用轻量级的Lighttpd、Nginx,不采用apache,apache最消耗内存.
Cache及反向代理
Squid
Lighttpd+mod_mem_cache
数据压缩
HTTP HEADER的Accept-Encoding
客户端缓存
HTTP HEADER的Expires、Cache-Control、Etag、Last-Modified参数设置
应用层优化
图片按需生成、图片预先生成、根据应用场景降低图片分辨率
图片处理工具的选择
可能大多数网站都是选择 ImageMagick 做为基础库,如果图片处理量巨大,性能问题又怎能不考虑?
防盗链
图片相当占用资源,一定要做好防盗链