现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片，如果前期没有很好的规划，那么随着图片文件的增多，无论是管理还是性能上都带来很多问题。就自己的一点理解，抛砖引玉，以期能引出更具价值的信息。
事关图片的存储
把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备，那么简单的很；如果有能力自己开发单独存储图片的文件系统，那么也不用接着往下看了。
如果上述条件不具备，只想在普通的硬盘上存储，首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的，实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ，怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑，选择合适大小的 inode size ，在空间和速度上做取舍，同时防患于未然，注意单个文件系统下文件个数别达到极限。
独立，独立的服务器
无论从管理上，还是从性能上看，只要有可能，尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后，在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd 。
如果不想在几台机器间同步所有图片，只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题，以及 NFS 特定的传输速度。
独立，独立的域名
如果大部分 Web 页面必须要载入很多图片，那么需要注意 IE 浏览器的连接数问题(参见对该问题的测试)。
前几天有个朋友在线上问我，”一些大网站，图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?” ，粗糙一点的答案：除了管理方便，便于CDN 同步处理，上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知，有请 Yahoo！的同学发言) 【还有一个我没考虑到的是 Cookie 的因素，参加楼下高春辉的留言】
雅虎 Web 优化 14 条
关于雅虎 YSlow 工具倡导的 优化 14 条规则，建议每个 Web 维护人员必须倒背如流，当然也应该辩证来看–介绍这 14 条规则的页面本身也只能得到 70 多分…其中的第九条和上面说的独立域名之间多少有些矛盾。实际情况要根据自己的 Benchmark 与具体需求而确定了。
有效利用客户端 Cache
很多网站的 UI 设计人员为了达到某些视觉效果，会在一些用户需要频繁访问的页面模块上应用大量的图片。这样的情况，研究表明，对于用户粘度比较高的站点， 在Web 服务器上对这一类对象设置 Expires Header 就是十分有必要的，大量带宽就这么节省下来，费用也节省了下来。顺便说一下，对于验证码这样的东西，要加个简单的规则过滤掉。
服务器端的 Cache
在国内，CDN 也是有钱才能玩得起。而类似 Amazon S3 这样的一揽子存储服务，国内还没有出现。所以，充分利用服务器端的 Cache 也是有必要的。Squid 作为反向代理服务器，缓冲图片效果应该说尚可，新浪技术团队贡献的 Ncache 据评测，效果更佳。
服务器端做Cache的好处是显而易见的，一个数据对象的请求时间会控制在 100ms 以内，否则的话，至少要几百个 ms 甚至更长。
高解析图片问题
如果网站存在大量高解析度的图片，那么有必要考虑部署 IIPImage 或者类似的软件。
运营问题
很多比较有规模的网站对于用户上传的图片不做任何处理，结果页面上还能看到很多 BMP 格式的图片(个人觉得任何网站出现 BMP 格式的图片都是可耻的)…这完全是运营上的策略之误了。找个程序员投入一点时间写个图片处理模块，对那些”截屏”得来的图片做个转换，投入成本可能远比存储上的开销小，而用户再访问该图片，质量未必能有什么损失，浏览速度无疑好多了。哪种处理方式更让人接受，不言而喻。
–EOF–
图片处理工具的选择
可能大多数网站都是选择 ImageMagick 做为基础库，不过这里也有一篇 GraphicsMagick 1.2 vs ImageMagick 6.3.6 Benchmark Report，如果图片处理量巨大，性能问题又怎能不考虑?
Lighttpd 的 ModCache 模块非常值得推荐。
Updated: 对于创业团队来说，推荐又拍云服务，用了都说好。
似乎我是第一个，
刚才在看google reader上的订阅，转眼间出现一个新的，赶紧过来吃了。
@海风
晕，这也抢沙发…
心有些乱, 没整理好. 后续再补充些细节内容吧
关于图片服务器使用独立域名的问题，我的解释。
使用独立的域名，不光是可以并发连接的问题，还有一个重要因素是可以避免 COOKIE 的影响。
果然转行做架构了。
多个域名关键是有一个dns查询的开销，当然，可以针对某几个域名进行ttl的调整。我觉得最大的还是是cookie的影响！
这里跟大家分享一个经验：如果每天图片增量有100G的话，那么一般情况下，存储用3台750*6（RAID5）的存储就够了。当然看压力适当加cache。
图片方面的网站是我一直关注的，比如zooomr，虽然期望很高，但是也让人很失望。
fenng说的算是比较粗略的，其实简单说，如果有钱，就用硬件换效率，如果没钱，就从软件上想办法，不过软件能提高的其实也就那么多。
国内做图片服务器的主要担忧其实不是服务器。。。。。。
Cookie具体如何影响，愿闻一二。
刚才用openid.cn的帐户登陆这里失败了，
Cookie 在http头里面，
http头不同影响缓存命中。
我是这么理解的，错了请指正
哦，这个原因，恩，有道理。
@aw
就是 taobao.com 域下的 Cookie 信息不会被带到 taobaoimg.com 域下，提高了图片服务器解析 header 头的速度。
储存介质用NAS其实是不Web 2.0的做法
更好的是用MogileFS这种分布式文件系统
我所知道不少Web 2.0的网站就在用这个
把容量、备份、同步都解决了
用独立的图片域名甚至更多的域名（例如img1. img2.）的做法，是因为IE等浏览器对单一域名有并发限制，最明显的例子就是如果你打开一个有几十张图片的网页的时候，图片是一张一张出来的，即使你的带宽足够
CDN是肯定要做的，难道不解决南北问题了？
（题外话，你用的openid插件不支持昵称）
长见识了！
恩，我考虑对我的blog进行同样的优化，哇哈哈哈~~~
今天才看到这个帖子
taobao就建立有大量自己的cdn站点与自己的分布式文件系统。
关于独立域名，上面的同学说得对，cookie的影响是很大的。如果处理的合理，可以节省大量的带宽费用。
有问题请教各位：
我在开发一个多用户blog，分配给用户二级域名。cookie的作用域是 .domain.com
那么我的静态内容域名和图片域名不能使用 static.domain.com,只能换别的域名了吗？
换别的域名对网站有何影响？
关注piner的评论
很想知道taobao的cdn实现方式 bind+squid?
还有分布式文件系统 现有的还是自己开发的?
在 程序员 上看到这篇文章了 ~
Yahoo 14 Rules 去掉了~
在《程序员》上看了你这篇文章的详细版，里面有写到图片服务器由于读操作密集，所以不能用raid5，能说一下为什么吗？我记得raid5只是写的性能比较低，读应该还是可以的。
实际上还会碰到许多问题
1.文件的重复性问题(许多用户上传相同内容的文件)
2.文件的重复存储问题(如果简单实用同步,就会发现每个文件在N台服务器上都有留存,增高了存储成本)
3.备份问题(那么多文件备份是件很头疼的问题,特别是那么多小文件)
最后这个解决方案,会越来越类似google file system或者mogilefs
受教了。
这篇文章非常好，不过服务器解析cookie头的时候真的很费时吗？
请问博主这个报告还有吗？
GraphicsMagick 1.2 vs ImageMagick 6.3.6 Benchmark Report
蛮有新意的，呵呵，我想独立图片服务器的其他好处还有：
1）便于独立权限管理和存储优化
2）便于WEB SERVER的访问调优
冯哥，是这样的，我在别处已经读到过你这篇文章，不过转载来转载去，已经变得有些面目全非了。
我想请教一个问题，我们做的一个B2C网站，因为是珠宝类的，对于图片的要求非常高，我们自己的投资并不足，所以想到利用yupoo的图片管家服务，这样的话我们网站的图片基本都是存储在yupoo了。速度不算特别快，但是比我们自建服务器好多了。yupoo的技术实力作为yupoo普通用户我非常信赖。我们自己的VPS流量降下来很多，速度提高很多。
但是后来有朋友建议说这样的图片地址（http://pic.yupoo.com/username/xxxxx.jpg）非常不利于搜索引擎优化！他讲到的几个原则似乎我们都违反了：1、命名中含有关键字；2、放在自己的服务器上，否则可能会被认为是盗链；
关于这个问题我上网查询了一些资料，在月光博客中还看到有人这么说：我真是不能理解某些图片存储服务商，不但拿走了人家的流量，还要收费。留言中很多人就认为是yupoo。
我凌乱了！求冯哥指点啊！
——————
这个，我知道说实话可能会得罪一些人，但是，这个只是牵涉技术交流，并无道德评判。
我不知道你说的“朋友”究竟对SEO理解有多深，但我可以说，这个和SEO没有实际的关系，基本上等同于扯淡。
你这样考虑好了：国外有大量的网站在用Amazon之类的云存储服务，难道他们都傻透了么？
呵呵，冯哥回的速度挺快的哈，请允许我把这个源地址贴上，如果不便通过留言审核的话，直接删除吧。以免引起不必要的误会。
http://www.williamlong.info/archives/1330.html 我是29#的回复，加上提建议的是以前搜房网的一个朋友，心里忐忑了半天。
既然冯哥这么说，而且我现在用的也确实很不错，yupoo的API接入后舒服的很，还是现在这样就好了，其他方面注意一下优化即可。
你提到的那个Blog中的观点颇有些脑残，难道网络上带宽是免费的？
别人帮你承担带宽，提升你页面的访问速度，收费（如果收费的话）不是天经地义的么？
做事情是以用户体验为上还是以SEO为上？不是目标用户SEO来有个鸟用呢？
你好，博主，读了你的这篇博文，我尝试使用了 GraphicsMagick 这个图片处理工具。测试发现，在本地环境下， GraphicsMagick的确是比ImageMagick快很多，特别是内存优化这一块，GM做得更为出色。但真正放上线后，GM的处理速度就慢很多了，有时候上传一张图片，GM处理，可能会达到10秒的时间，而在同一环境下，IM要快很多；初步认为，GM存在并发处理上的问题，诚心请教，我该如何解决这个问题，或者提供一点思路，指点指点后辈，谢谢！
图片使用独立的域名，访问图片的http请求不会夹带之前请求的cookie信息，减少cookie信息。
图片服务器还应该包含一整套图片的接口，保存，获取，生成缩略。
对外应该屏蔽文件系统信息。
具体的存储位置由图片服务器来决定，或者说设定几种可选的位置，变成接口的参数，但是接口不用关心具体的文件目录。