閑談 Web 圖片伺服器應用分析

就自己的一點理解，拋磚引玉，以期能引出更具價值的資訊。

事關圖片的儲存
把圖片儲存到什麼介質上? 如果有足夠的資金購買專用的圖片伺服器硬體或者 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 作為反向 Proxy伺服器，緩衝圖片效果應該說尚可，新浪技術團隊貢獻的 Ncache 據評測，效果更佳。

高解析圖片問題
如果網站存在大量高解析度的圖片，那麼有必要考慮部署 IIPImage 或者類似的軟體。

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