閒談 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！的同窗發言) 【還有一個我沒考慮到的是 Cookie 的因素，參加樓下高春輝的留言】

雅虎 Web 優化 14 條

關於雅虎 YSlow 工具倡導的 優化 14 條規則，建議每一個 Web 維護人員必須滾瓜爛熟，固然也應該辯證來看--介紹這 14 條規則的頁面自己也只能獲得 70 多分...其中的第九條和上面說的獨立域名之間多少有些矛盾。實際狀況要根據本身的 Benchmark 與具體需求而肯定了。

有效利用客戶端 Cache

不少網站的 UI 設計人員爲了達到某些視覺效果，會在一些用戶須要頻繁訪問的頁面模塊上應用大量的圖片。這樣的狀況，研究代表，對於用戶粘度比較高的站點， 在Web 服務器上對這一類對象設置 Expires Header 就是十分有必要的，大量帶寬就這麼節省下來，費用也節省了下來。順便說一下，對於驗證碼這樣的東西，要加個簡單的規則過濾掉。

服務器端的 Cache

在國內，CDN 也是有錢才能玩得起。而相似 Amazon S3 這樣的一攬子存儲服務，國內尚未出現。因此，充分利用服務器端的 Cache 也是有必要的。Squid 做爲反向代理服務器，緩衝圖片效果應該說尚可，新浪技術團隊貢獻的 Ncache 據評測，效果更佳。

高解析圖片問題

若是網站存在大量高解析度的圖片，那麼有必要考慮部署 IIPImage 或者相似的軟件。

運營問題

不少比較有規模的網站對於用戶上傳的圖片不作任何處理，結果頁面上還能看到不少 BMP 格式的圖片(我的以爲任何網站出現 BMP 格式的圖片都是可恥的)...這徹底是運營上的策略之誤了。找個程序員投入一點時間寫個圖片處理模塊，對那些"截屏"得來的圖片作個轉換，投入成本可能遠比存儲上的開銷小，而用戶再訪問該圖片，質量未必能有什麼損失，瀏覽速度無疑好多了。哪一種處理方式更讓人接受，不言而喻。