闲谈Web网站图片服务器
现在很多中小网站(尤其是 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！的同学发言)
雅虎 Web 优化 14 条
关于雅虎 YSlow 工具倡导的 优化 14 条规则，建议每个 Web 维护人员必须倒背如流，当然也应该辩证来看–介绍这 14 条规则的页面本身也只能得到 70 多分…其中的第九条和上面说的独立域名之间多少有些矛盾。实际情况要根据自己的 Benchmark 与具体需求而确定了。
有效利用客户端 Cache
很多网站的 UI 设计人员为了达到某些视觉效果，会在一些用户需要频繁访问的页面模块上应用大量的图片。这样的情况，研究表明，对于用户粘度比较高的站点， 在Web 服务器上对这一类对象设置 Expires Headr就是十分有必要的，大量带宽就这么节省下来，费用也节省了下来。顺便说一下，对于验证码这样的东西，要加个简单的规则过滤掉。
服务器端的 Cache
在国内，CDN 也是有钱才能玩得起。而类似 Amazon S3 这样的一揽子存储服务，国内还没有出现。所以，充分利用服务器端的 Cache 也是有必要的。Squid 作为反向代理服务器，缓冲图片效果应该说尚可，新浪技术团队贡献的 Ncache据评测，效果更佳。
高解析图片问题
如果网站存在大量高解析度的图片，那么有必要考虑部署 IIPImage 或者类似的软件。
运营问题
很多比较有规模的网站对于用户上传的图片不做任何处理，结果页面上还能看到很多 BMP 格式的图片(个人觉得任何网站出现 BMP 格式的图片都是可耻的)…这完全是运营上的策略之误了。找个程序员投入一点时间写个图片处理模块，对那些”截屏”得来的图片做个转换，投入成本可能远比存储上的开销小，而用户再访问该图片，质量未必能有什么损失，浏览速度无疑好多了。哪种处理方式更让人接受，不言而喻。
