图片服务器架构
现在很多中小网站都允许用户上传图片，如果前期没有很好的规划，那么随着图片文件的增多，无论是管理还是性能上都带来很多问题。就自己的一点理解纯属理论,没经验证,谨慎参考。
在当前的经济形势下，遵循“少花钱、多办事”的原则，采用纯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 做为基础库，如果图片处理量巨大，性能问题又怎能不考虑?
防盗链
图片相当占用资源,一定要做好防盗链
欢迎转载,请注明出处:亲亲宝宝