nginx 圖片服務

網上找的，感受還不錯

1 介紹

如今不少的網站上都會用到大量的圖片，而圖片是網頁傳輸中佔主要的數據量,也是影響網站性能的主要因素。所以不少網站都會將圖片存儲從網站中分離出來，另外架構一個或多個服務器來存儲圖片，將圖片放到一個虛擬目錄中，而網頁上的圖片都用一個URL地址來指向這些服務器上的圖片的地址，這樣的話網站的性能就明顯提升了，圖片服務器(ImageServer)的概念也就產生了。

1.1 圖片服務器的優點

 

1， 分擔Web服務器的I/O負載-將耗費資源的圖片服務分離出來，提升服務器的性能和穩定性。

2， 可以專門對圖片服務器進行優化-爲圖片服務設置有針對性的緩存方案，減小帶寬成本，提升訪問速度。

3， 提升網站的可擴展性-經過增長圖片服務器，提升圖片吞吐能力。

 

1.2 圖片服務器的注意事項

1， 選擇適合圖片存儲的物理介質和文件系統

2， 使用物理上獨立的服務器

3， 若是擁有多臺圖片服務器，要考慮服務器之間的圖片同步問題

4， 使用獨立域名

5， 制定合理的緩存策略

6， 使用圖片處理模塊對用戶上傳的圖片進行再加工

1.3 圖片服務器的架構

圖片是網站中必不可少的一個組成部分，隨着網站的不斷髮展，對圖片的處理也將隨着訪問的增加，圖片的增長提出不斷改進的需求， 網站初期，全部的一切都從簡圖片所存在的位置一般會在站點下的Images文件夾。

隨着訪問的增長，IIS壓力的增大，開始作拆分，將圖片文件夾做爲單獨站點提取出來如http://images.***.com/(可能根據須要會拆分紅多個圖片服務器，與具體業務環境相關)，拆分以後很好的將單個IIS應用池的壓力分擔到2個乃至多個上，大大提升訪問瓶頸。隨着訪問的進一步增長，服務器壓力已經沒法支撐，這時咱們須要將圖片站點做爲獨立服務器存在。在訪問圖片的過程當中，咱們可能會面臨一個圖片有多個圖片尺寸的需求，前期咱們一般會在保存頁面的過程當中保存咱們須要的各個尺寸圖片，但隨着所需尺寸的不一樣，保存圖片時須要的尺寸愈來愈多，這時咱們如何應對？

IIS服務器的併發訪問意味着隨着用戶的進一步增長，咱們單臺圖片服務器已經不足以應對了，此時咱們如何進一步擴展？

 

如上圖所示，咱們此時可針對這兩個問題作出統一解決方案，在前端添加squid緩存服務器，添加一臺或者多臺動態切圖服務器。Squid或者Nginx代理緩存服務器可以極大的提高圖片系統的併發訪問，使系統突破現有限制。動態切圖服務器主要的做用是針對不一樣尺寸的圖片訪問調取原圖臨時生成符合需求的圖片並返回。原圖的存儲區能夠與圖片服務放在一塊兒，也能夠講圖片放於單獨的服務器上。

在此種結構中，併發的最大訪問限制將是squid或者其餘代理服務器的系統瓶頸，當切圖服務壓力增大時，只需添加相應切圖服務器便可，圖片存儲區的增加也可經過添加硬盤或者服務器進行解決。

若是您的站點訪問量還在進一步增加，squid的訪問瓶頸即將被突破，這時咱們又該如何應對呢？

 

如上圖所示，採用多臺Squid或Nginx服務器，在前端添加F5或LVS負載均衡(同時還可開啓緩存功能)。此時將極大提高訪問的併發量，能夠根據狀況隨時調配服務器。固然此時也存在必定的瑕疵，那就是可能在多臺Squid上存在同一張圖片，由於訪問圖片時可能第一次分到squid1，在F5過時後第二次訪問到squid2或者別的，固然相對併發問題的解決，此種少許的冗餘徹底在咱們的容許範圍以內。在作了這許多的工做後，若是條件容許對圖片服務器作下CDN，那將會對您站點的圖片訪問質量有更大的提高。

 

1.4 圖片存儲架構

1.4.1 部署獨立圖片服務器的必要性

咱們知道，不管對於Apache仍是IIS，圖片始終是最消耗系統資源的，若是將圖片服務和應用服務放在同一個服務器的話，應用服務器很容易會由於圖片的高I/O負載而崩潰，所以對於有些大型網站項目，咱們有必要將圖片服務器和應用服務器分離。部署獨立的圖片服務器（甚至是服務器集羣）是大型網站圖片存儲解決方案中最基礎的，由於有了獨立的圖片服務器後，咱們才能對圖片服務器作更有針對性的性能優化，好比從硬件角度說，圖片服務器能夠配置高端的硬盤，7200轉的換成15000轉的，而CPU卻只要通常就能夠了；從軟件角度說，能夠爲圖片服務器配置特殊的文件系統來知足對圖片的I/O請求，如淘寶的TFS，就很好地解決了大規模小圖片文件帶來的I/O噩夢，同時，咱們也能夠採用nginx、squid來代理圖片請求等等。

 

1.4.2 採用獨立域名

注意，這裏是指獨立域名，不是子域哦，好比yahoo.com圖片服務器用了yimg.com的域名，而不是用二級域名img.yahoo.com，這是爲何呢？我的以爲緣由主要有如下幾點：

一、同一域名下瀏覽器的併發鏈接數有限制，通常在2 - 6之間，下圖列舉了各個瀏覽器的併發鏈接數（下圖供參考）

    

這樣，咱們若是給圖片服務器配置獨立的域名，那麼在一個頁面中加載圖片時，就能夠突破瀏覽器鏈接數的限制，理論上，增長一個獨立域名，併發鏈接數加倍。

二、因爲cookie的緣由，對緩存不利

好比有一張圖片http://www.test.com/img/xx.gif，那麼當咱們向它發起請求的時候，會帶上www.test.com域名下的cookie，因爲大部分web cache都只緩存不帶cookie的請求，這樣就致使每次的圖片請求都不能命中cache，而仍舊要去原始服務器獲取圖片，致使圖片緩存意義不大。因此，仍是給單獨搞一個圖片獨立域名吧，固然，不僅是圖片，css和js文件也能夠參照這個思路來搞。

三、方便CDN同步

 

1.4.3 圖片服務器分離後，如何進行圖片上傳和圖片同步

固然任何事物都具備兩面性，圖片服務器分離當然提高了圖片訪問的效率，大大緩解了服務器因圖片形成的I/O瓶頸，可是分離之後圖片的上傳和同步就成了一個大問題了。下面就我我的的想法談談幾種解決方案。

一、NFS共享方式

若是你不想在每臺圖片服務器同步全部圖片，那NFS共享是最簡單也最實用的方式。NFS是個分佈式的客戶機/服務器文件系統，NFS的實質在於用戶間計算機的共享，用戶能夠聯結到共享計算機並象訪問本地硬盤同樣訪問共享計算機上的文件。

具體實現思路是：web服務器經過nfs掛載多臺圖片服務器export出來的目錄，用戶先將圖片上傳到web服務器，而後將上傳的圖片經過程序拷貝到這個mount目錄中去，這樣那幾臺圖片服務器就也能訪問到剛上傳的圖片了（注意，只是共享了，並無真正拷貝到圖片服務器）。再給那幾臺圖片服務器綁定獨立域名，因而瀏覽器端就能夠用單獨的域名來訪問圖片了。這種方式基本不會有因同步形成的延時，但須要依賴nfs，nfs掛掉會影響web服務器。以下圖

至於如何配置nfs，你們google一下，或者看一下這篇文章，是在Linux下配置NFS的http://blog.csdn.net/lixinso/article/details/6639643

二、利用FTP同步

和上面nfs不同的是，用戶上傳完圖片後是利用ftp同步到各個圖片服務器的，php、java、asp.net基本上都能操做ftp。這樣的話每一個圖片服務器就都保存一份圖片的副本，也起到了備份的做用。可是缺點是將圖片ftp到服務器比較耗時，若是異步去同步的話又會有延時，不過通常的小圖片文件也還好了。

 

2 圖片服務器的URL HASH架構剖析 

2.1 什麼是url hash 架構

url hash架構對url進行一次hash算法，而後經過hash結果找到對應的服務器。由於針對單一個url的hash結果是同樣的，因此理論上這個url會被永久分配到固定的一臺服務器上。另外由於通過了hash算法，因此分配url就很均勻，同時訪問量也能夠達到均衡。

 

2.2 爲何要用url hash架構 

1, 圖片服務器的特色一是訪問量很大，二是容量也很大，經過簡單的負載均衡，能夠解決訪問量大的問題，可是容量的問題並無改善。因此會形成容災問題。

2, 容災問題：系統某個時間段被訪問的數據嚴重超出緩存集羣中最小單機的容納容量就會形成容災，容災會使大量單一連接穿透，直接對後臺的IO性能影響很大。

3, 雖然能夠經過增長緩存容量的配置來解決容災問題，可是內存老是有限的，爲每一臺機器增長超大內存成本上也開銷很大，另外在squid中也不宜配置很大的磁盤緩存，不然squid中的hash表會很大，性能不好。

4, 經過hash架構，能夠充分利用緩存集羣的內存，容災問題就再也不取決於緩存集羣中最小單機的容納容量，而是緩存集羣中全部機器的容納容量之和。

2.3 各類url hash架構

1）基於dns的hash架構。

2）基於nginx的自動hash架構。

3）基於nginx的手動hash架構。

 

2.3.1 基於dns的hash架構

dns的hash架構圖

 

 

dns的hash架構說明

這個架構適合面向用戶的圖片系統，好比論壇、相冊、博客中的圖片上傳。這樣它纔可以保證文件名有一致的規範。

這個架構圖分了36個域名，圖片文件名是用md5值起的，在md5值中取一位字母就能夠代表它是在哪一個域名裏，域名就對應了機器，上傳分發的時候也是根據此字母來分發。

 

dns的hash架構的優缺點

優勢：

1）使用了dns分流，成本較低，並且dns性能高，不用維護。

2）可突破IE默認每主機2個線程的限制。

缺點：

1）可用性方面，若是有一臺機器宕機，則指向這臺機器的請求沒法讀取。

2）分流方面，只能所有同步，成本較高

3）只適用於面向用戶的系統

 

2.3.2 基於nginx的自動手動hash架構

nginx的自動hash架構圖

 

nginx的自動hash架構說明

1, 這是一種新的緩存架構，由nginx做爲最前端，代理到緩存機器。

2, nginx後面是緩存組，由nginx通過url hash後將請求分到緩存機器。

3, 這個架構方便純squid緩存升級，能夠在squid的機器上加裝nginx。

4, nginx有緩存的功能，能夠將一些訪問量特大的連接直接緩存在nginx上，就不用通過多一次代理的請求。好比favicon.ico和網站的logo。

nginx的自動hash架構優缺點

優勢

1）高性能

2）使用方便，後臺是什麼樣關係不大

3）有很高的可用性

4）緩存架構，分流方便

5）可直接在nginx代理緩存部分連接

缺點

url分流可控性弱，增減緩存機器都會引發緩存從新分配，意味着緩存所有失效。

 

nginx的手動hash架構說明

1，這個架構圖和自動hash的架構是同樣的，惟一有差異的是hash算法的變化，自動hash是用nginx upstream hash模塊自帶的hash算法來實現分流，這個手動架構是本身設計一個算法來實現。

2，算法設計思路是從url中取一個字符來做分流依據，好比定義連接的倒數第10個字符來分流，一樣能夠分配得很均勻。

3，手動架構能夠避免自動架構中增減機器帶來的緩存失效問題，另外能夠精確知道一個連接到底存在哪臺緩存上。

 

nginx的手動hash架構優缺點

優勢

1）基本能夠繼承自動架構的優勢

2）避免增減機器的問題

3）精確知道連接存儲在哪臺緩存上

缺點

配置較複雜，要分配均勻配置不易。

 

採用Hash架構對bbs架構優化

 

1，先前講的bbs架構採用的是lvs+squid做爲前端，這樣的話squidclient更新緩存時須要更新全部的squid，這個效率很低下，使用hash架構就可使squidclient每次只須要清理一臺squid，效率大爲提高。

2，推薦的是使用nginx手動hash架構，它能夠精確知道連接會存在哪臺機器上，這樣就能夠配置精確的備份機器。

 

3 nginx圖片服務器的架構方案

圖片服務一般數據容量較大，並且訪問也頻繁，鑑於此，圖片服務就會有兩種問題，一是存儲問題，二是訪問量問題。
存儲問題就是硬盤容量問題， 花錢買硬盤就能夠了，看似簡單，但着實也是最苦的問題。按目前探索來看，最好的方式是：在任什麼時候刻遇到硬盤空間不夠時，買顆硬盤插上，最多改改配置，就能 馬上利用；另外，硬盤要能充分利用，否則圖片存儲量大再加上備份，很恐怖，最好是每顆硬盤都用上100%的空間。
訪問量也是個大問題，如 果服務不容許防盜鏈，那麼訪問量會引發帶寬、服務器壓力等問題，有錢的話直接扔CDN，沒錢或者有更多的錢，就本身作吧。根據垣古不變的真理「越老的圖， 訪問量也相對較少」這一點，分紅兩大部分，一邊處理最新的圖片，一邊處理老舊的圖片。最新的圖片訪問量大，但存儲量較少；老圖片訪問量低，但存儲量大。

 

3.1 擬定一個存儲目錄規則

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

3.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空間就能夠了。