圖片服務器優化 解決流量和存儲問題

圖片服務一般數據容量較大，並且訪問也頻繁，鑑於此，圖片服務就會有兩種問題，一是存儲問題，二是訪問量問題。

　　存儲問題就是硬 盤容量問題，花錢買硬盤就能夠了，看似簡單，但着實也是最苦的問題。按目前探索來看，最好的方式是：在任什麼時候刻遇到硬盤空間不夠時，買顆硬盤插上，最多改 改配置，就能馬上利用；另外，硬盤要能充分利用，否則圖片存儲量大再加上備份，很恐怖，最好是每顆硬盤都用上100%的空間。

　　訪問量 也是個大問題，若是服務不容許防盜鏈，那麼訪問量會引發帶寬、服務器壓力等問題，有錢的話直接扔CDN，沒錢或者有更多的錢，就本身作吧。根據垣古不變的 真理「越老的圖，訪問量也相對較少」這一點，分紅兩大部分，一邊處理最新的圖片，一邊處理老舊的圖片。最新的圖片訪問量大，但存儲量較少；老圖片訪問量 低，但存儲量大。

大概分析完了，開始制定方案。

1、擬定一個存儲目錄規則：

　　在現有的/a/b/abcde.jpg這樣的hash方式下多加一個日期的目錄變成：/200810/16/a/b/abcde.jpg或者/2008/10/16/a/b/abcde.jpg。按日期制定這個目錄規則後，就能夠按年月來拆機器了。

2、分機器，分硬盤

　 　按以前的計劃，分紅兩個組，一組服務器用lvs作負載均衡負責新圖片；另外一組服務器作舊圖片訪問和備份。新圖機器找幾臺好點的服務器，SCSI硬盤；舊 圖機器沒太大要求，PC機就行，找夠硬盤就能夠，如今IDE的1T硬盤也不太貴，最好再搭個raid就省事了，最主要是這些機器要多。

說明一下：

1. 圖片服務經過lvs做爲入口，處理能力上仍是有保障的。
2. 利用nginx直接對外服務，沒必要用squid。
3. 圖中的紅線是指主nginx會將/2006和/2007年的圖片分別代理到兩臺存檔服務器，若是發現主nginx的cpu佔用比較大，那麼能夠考慮使用nginx的proxy_store將圖片存到主服務器上，按期清理。
4. 圖中有一臺存儲分配服務器，做爲圖片服務更新圖片的統一入口，有新圖片或者修改圖片的話，由這臺服務器負責將圖片放到正確的服務器上去。
5. 舊圖片服務器當前用年份來劃分，每一年增長兩臺服務器，亦但是加兩塊硬盤，注意，不要相信raid，必定要有兩臺機器，地理上分在兩個城市則更好。
6. 由於舊數據2006和2007年的數據基本上是沒有變化的，因此假如硬盤夠大，那麼能夠把兩年的數據合併在一塊兒。
7. 若是細心定製，那麼舊圖片服務器的硬盤100%塞盡是能夠的，舊數據的容量基本上不會大幅增加，小小預留1-2G空間就能夠了。

　　使用這個架構的話，硬盤不夠的話，加硬盤就能夠了。若是圖片量實在太大，主服務器連一年的數據都裝不下，那能夠用啓用月份來劃分；若是一個月都裝不下了，那也太誇張了，那就啓用日期吧；若是一天的數據都裝不下，那就使用小時，依次類推。