圖片服務器架構
現在很多中小網站都允許用戶上傳圖片，如果前期沒有很好的規劃，那么隨著圖片文件的增多，無論是管理還是性能上都帶來很多問題。就自己的一點理解純屬理論,沒經驗證,謹慎參考。
在當前的經濟形勢下，遵循“少花錢、多辦事”的原則，采用純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 做為基礎庫，如果圖片處理量巨大，性能問題又怎能不考慮?
防盜鏈
圖片相當占用資源,一定要做好防盜鏈
來自：http://blog.csdn.net/jiangfeng08/article/details/7646663
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！