Nginx圖片服務器的架構方案

圖片服務有兩種問題，一是存儲問題，二是訪問量問題。
存儲問題就是硬盤容量問題，花錢買硬盤就能夠了，看似簡單，但着實也是最苦的問題。按目前探索來看，最好的方式是：在任什麼時候刻遇到硬盤空間不夠時，買顆硬盤插上，最多改改配置，就能馬上利用；另外，硬盤要能充分利用，否則圖片存儲量大再加上備份，很恐怖，最好是每顆硬盤都用上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就省事了，最主要是這些機器要多。

說明一下：
一、圖片服務經過lvs做爲入口，處理能力上仍是有保障的。

二、利用nginx直接對外服務，沒必要用squid。

三、圖中的紅線是指主nginx會將/2006和/2007年的圖片分別代理到兩臺存檔服務器，若是發現主nginx的cpu佔用比較大，那麼能夠考慮使用nginx的proxy_store將圖片存到主服務器上，按期清理。

四、圖中有一臺存儲分配服務器，做爲圖片服務更新圖片的統一入口，有新圖片或者修改圖片的話，由這臺服務器負責將圖片放到正確的服務器上去。

五、舊圖片服務器當前用年份來劃分，每一年增長兩臺服務器，亦但是加兩塊硬盤，注意，不要相信raid，必定要有兩臺機器，地理上分在兩個城市則更好。

六、由於舊數據2006和2007年的數據基本上是沒有變化的，因此假如硬盤夠大，那麼能夠把兩年的數據合併在一塊兒。

七、若是細心定製，那麼舊圖片服務器的硬盤100%塞盡是能夠的，舊數據的容量基本上不會大幅增加，小小預留1-2G空間就能夠了。
使用這個架構的話，把去年的數據想辦法遷到舊圖服務器上，硬盤不夠的話，加硬盤就能夠了。若是圖片量實在太大，主服務器連一年的數據都裝不下，那能夠用啓用月份來劃分；若是一個月都裝不下了，那也太誇張了，那就啓用日期吧；若是一天的數據都裝不下，那就……