圖片服務器分離1 介紹現(xiàn)在很多的網(wǎng)站上都會用到大量的圖片，而圖片是網(wǎng)頁傳輸中占主要的數(shù)據(jù)量, 也是影響網(wǎng)站性能的主要因素。因此很多網(wǎng)站都會將圖片存儲從網(wǎng)站中分離出來，另外架構(gòu)一個或多個服務器來存儲圖片

圖片服務器分離

1 介紹

現(xiàn)在很多的網(wǎng)站上都會用到大量的圖片，而圖片是網(wǎng)頁傳輸中占主要的數(shù)據(jù)量, 也是影響網(wǎng)站性能的主要因素。因此很多網(wǎng)站都會將圖片存儲從網(wǎng)站中分離出來，另外架構(gòu)一個或多個服務器來存儲圖片，將圖片放到一個虛擬目錄中，而網(wǎng)頁上的圖片都用一個URL 地址來指向這些服務器上的圖片的地址，這樣的話網(wǎng)站的性能就明顯提高了，圖片服務器(ImageServer)的概念也就產(chǎn)生了。

1.1

圖片服務器的優(yōu)勢

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

2， 能夠?qū)ｉT對圖片服務器進行優(yōu)化-為圖片服務設置有針對性的緩存方案，減少帶寬成本，提高訪問速度。

3， 提高網(wǎng)站的可擴展性-通過增加圖片服務器，提高圖片吞吐能力。

1.2 圖片服務器的注意事項

1， 選擇適合圖片存儲的物理介質(zhì)和文件系統(tǒng)

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

3， 如果擁有多臺圖片服務器，要考慮服務器之間的圖片同步問題 4， 使用獨立域名

5， 制定合理的緩存策略

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

1.3 圖片服務器的架構(gòu)

圖片是網(wǎng)站中必不可少的一個組成部分，隨著網(wǎng)站的不斷發(fā)展，對圖片的處理也將隨著訪問的增長，圖片的增加提出不斷改進的需求， 網(wǎng)站初期，所有的一切都從簡圖片所存在的位置通常會在站點下的Images 文件夾。

隨著訪問的增加，IIS 壓力的增大，開始做拆分，將圖片文件夾作為單獨站點提取出來如http://images.***.com/(可能根據(jù)需要會拆分成多個圖片服務器，與具體業(yè)務環(huán)境相關(guān)) ，拆分之后很好的將單個IIS 應用池的壓力分擔到2個乃至多個上，大大提高訪問瓶頸。隨著訪問的進一步增加，服務器壓力已經(jīng)無法支撐，這時我們需要將圖片站點作為獨立服務器存在。在訪問圖片的過程中，我們可能會面臨一個圖片有多個圖片尺寸的需求，前期我們通常會在保存頁面的過程中保存我們需要的各個尺寸圖片，但隨著所需尺寸的不同，保存圖片時需要的尺寸越來越多，這時我們?nèi)绾螒獙Γ?/p>

IIS 服務器的并發(fā)訪問意味著隨著用戶的進一步增加，我們單臺圖片服務器已經(jīng)不足以應對了，此時我們?nèi)绾芜M一步擴展？

如上圖所示，我們此時可針對這兩個問題做出統(tǒng)一解決方案，在前端添加squid 緩存服務器，添加一臺或者多臺動態(tài)切圖服務器。Squid 或者Nginx 代理緩存服務器能夠極大的提升圖片系統(tǒng)的并發(fā)訪問，使系統(tǒng)突破現(xiàn)有限制。動態(tài)切圖服務器主要的作用是針對不同尺寸的圖片訪問調(diào)取原圖臨時生成符合需求的圖片并返回。原圖的存儲區(qū)可以與圖片服務放在一起，也可以講圖片放于單獨的服務器上。

在此種結(jié)構(gòu)中，并發(fā)的最大訪問限制將是squid 或者其他代理服務器的系統(tǒng)瓶頸，當切圖服務壓力增大時，只需添加相應切圖服務器即可，圖片存儲區(qū)的增長也可通過添加硬盤或者服務器進行解決。

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

如上圖所示，采用多臺Squid 或Nginx 服務器，在前端添加F5或LVS 負載均衡(同時還可開啟緩存功能) 。此時將極大提升訪問的并發(fā)量，可以根據(jù)情況隨時調(diào)配服務器。當然此時也存在一定的瑕疵，那就是可能在多臺Squid 上存在同一張圖片，因為訪問圖片時可能第一次分到squid1，在F5過期后第二次訪問到squid2或者別的，當然相對并發(fā)問題的解決，此種少量的冗余完全在我們的允許范圍之內(nèi)。在做了這許多的工作后，如果條件允許對圖片服務器做下CDN ，那將會對您站點的圖片訪問質(zhì)量有更大的提升。

1.4 圖片存儲架構(gòu)

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

我們知道，無論對于Apache 還是IIS ，圖片始終是最消耗系統(tǒng)資源的，如果將圖片服務和應用服務放在同一個服務器的話，應用服務器很容易會因為圖片的高I/O負載而崩潰，因此對于有些大型網(wǎng)站項目，我們有必要將圖片服務器和應用服務器分離。部署獨立的圖片服務器（甚至是服務器集群）是大型網(wǎng)站圖片存儲解決方案中最基礎的，因為有了獨立的圖片服務器后，我們才能對圖片服務器做更有針對性的性能優(yōu)化，比如從硬件角度說，圖片服務器可以配置高端的硬盤，7200轉(zhuǎn)的換成15000轉(zhuǎn)的，而CPU 卻只要一般就可以了；從軟件角度說，可以為圖片服務器配置特殊的文件系統(tǒng)來滿足對圖片的I/O請求，如淘寶的TFS ，就很好地解決了大規(guī)模小圖片文件帶來的I/O噩夢，同時，我們也可以采用nginx 、squid 來代理圖片請求等等。

1.4.2 采用獨立域名

注意，這里是指獨立域名，不是子域哦，比如yahoo.com 圖片服務器用了yimg.com 的域名，而不是用二級域名img.yahoo.com ，這是為什么呢？個人覺得原因主要有以下幾點：

1、同一域名下瀏覽器的并發(fā)連接數(shù)有限制，一般在2 - 6之間，下圖列舉了各個瀏覽器的并發(fā)連接數(shù)（下圖供參考）

這樣，我們?nèi)绻o圖片服務器配置獨立的域名，那么在一個頁面中加載圖片時，就可以突破瀏覽器連接數(shù)的限制，理論上，增加一個獨立域名，并發(fā)連接數(shù)加倍。

2、由于cookie 的原因，對緩存不利

比如有一張圖片http://www.test.com/img/xx.gif，那么當我們向它發(fā)起請求的時候，會帶上www.test.com 域名下的cookie ，由于大部分web cache 都只緩存不帶cookie 的請求，這樣就導致每次的圖片請求都不能命中cache ，而仍舊要去原始服務器獲取圖片，導致圖片緩存意義不大。所以，還是給單獨搞一個圖片獨立域名吧，當然，不只是圖片，css 和js 文件也可以參照這個思路來搞。

3、方便CDN 同步

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

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

1、NFS 共享方式

如果你不想在每臺圖片服務器同步所有圖片，那NFS 共享是最簡單也最實用的方式。NFS 是個分布式的客戶機/服務器文件系統(tǒng)，NFS 的實質(zhì)在于用戶間計算機的共享，用戶可以聯(lián)結(jié)到共享計算機并象訪問本地硬盤一樣訪問共享計算機上的文件。

具體實現(xiàn)思路是：web 服務器通過nfs 掛載多臺圖片服務器export 出來的目錄，用戶先將圖片上傳到web 服務器，然后將上傳的圖片通過程序拷貝到這個mount 目錄中去，這樣那幾臺圖片服務器就也能訪問到剛上傳的圖片了（注意，只是共享了，并沒有真正拷貝到圖片服務器）。再給那幾臺圖片服務器綁定獨立域名，于是瀏覽器端就可以用單獨的域名來訪問圖

片了。這種方式基本不會有因同步造成的延時，但需要依賴nfs ，nfs 掛掉會影響web 服務器。如下圖 至于如何配置

nfs ，大家google 一下，或者看一下這篇文章，是在Linux 下配置NFS 的http://blog.csdn.net/lixinso/article/details/6639643

2、利用FTP 同步

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

2 圖片服務器的URL HASH架構(gòu)剖析

2.1 什么是url hash 架構(gòu)

url hash架構(gòu)對url 進行一次hash 算法，然后通過hash 結(jié)果找到對應的服務器。因為針對單一個url 的hash 結(jié)果是一樣的，所以理論上這個url 會被永久分配到固定的一臺服務器上。另外因為經(jīng)過了hash 算法，所以分配url 就很均勻，同時訪問量也可以達到均衡。

2.2 為什么要用url hash架構(gòu)

1, 圖片服務器的特點一是訪問量很大，二是容量也很大，通過簡單的負載均衡，可以解決訪問量大的問題，但是容量的問題并沒有改善。所以會造成容災問題。

2, 容災問題：系統(tǒng)某個時間段被訪問的數(shù)據(jù)嚴重超出緩存集群中最小單機的容納容量就會造成容災，容災會使大量單一鏈接穿透，直接對后臺的IO 性能影響很大。

3, 雖然可以通過增加緩存容量的配置來解決容災問題，但是內(nèi)存總是有限的，為每一臺機器增加超大內(nèi)存成本上也開銷很大，另外在squid 中也不宜配置很大的磁盤緩存，否則squid 中的hash 表會很大，性能很差。

4, 通過hash 架構(gòu)，可以充分利用緩存集群的內(nèi)存，容災問題就不再取決于緩存集群中最小單機的容納容量，而是緩存集群中所有機器的容納容量之和。

2.3 各種url hash架構(gòu)

1）基于dns 的hash 架構(gòu)。

2）基于nginx 的自動hash 架構(gòu)。

3）基于nginx 的手動hash 架構(gòu)。

2.3.1 基于dns 的hash 架構(gòu)

dns 的hash 架構(gòu)圖

dns 的hash 架構(gòu)說明

這個架構(gòu)適合面向用戶的圖片系統(tǒng)，比如論壇、相冊、博客中的圖片上傳。這樣它才能夠保證文件名有一致的規(guī)范。

這個架構(gòu)圖分了36個域名，圖片文件名是用md5值起的，在md5值中取一位字母就可以表明它是在哪個域名里，域名就對應了機器，上傳分發(fā)的時候也是根據(jù)此字母來分發(fā)。

dns 的hash 架構(gòu)的優(yōu)缺點

優(yōu)點：

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

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

缺點：

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

2）分流方面，只能全部同步，成本較高

3）只適用于面向用戶的系統(tǒng)

2.3.2 基于nginx 的自動手動hash 架構(gòu)

nginx 的自動hash 架構(gòu)圖

nginx 的自動hash 架構(gòu)說明

1, 這是一種新的緩存架構(gòu)，由nginx 作為最前端，代理到緩存機器。

2, nginx后面是緩存組，由nginx 經(jīng)過url hash后將請求分到緩存機器。

3, 這個架構(gòu)方便純squid 緩存升級，可以在squid 的機器上加裝nginx 。

4, nginx 有緩存的功能，可以將一些訪問量特大的鏈接直接緩存在nginx 上，就不用經(jīng)過多一次代理的請求。比如favicon.ico 和網(wǎng)站的logo 。

nginx 的自動hash 架構(gòu)優(yōu)缺點

優(yōu)點

1）高性能

2）使用方便，后臺是什么樣關(guān)系不大

3）有很高的可用性

4）緩存架構(gòu)，分流方便

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

缺點

url 分流可控性弱，增減緩存機器都會引起緩存重新分配，意味著緩存全部失效。

nginx 的手動hash 架構(gòu)說明

1，這個架構(gòu)圖和自動hash 的架構(gòu)是一樣的，唯一有差別的是hash 算法的變化，自動hash 是用nginx upstream hash模塊自帶的hash 算法來實現(xiàn)分流，這個手動架構(gòu)是自己設計一個算法來實現(xiàn)。

2，算法設計思路是從url 中取一個字符來作分流依據(jù)，比如定義鏈接的倒數(shù)第10個字符來分流，同樣可以分配得很均勻。

3，手動架構(gòu)可以避免自動架構(gòu)中增減機器帶來的緩存失效問題，另外可以精確知道一個鏈接到底存在哪臺緩存上。

nginx 的手動hash 架構(gòu)優(yōu)缺點

優(yōu)點

1）基本可以繼承自動架構(gòu)的優(yōu)點

2）避免增減機器的問題

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

缺點

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

采用Hash 架構(gòu)對bbs 架構(gòu)優(yōu)化

1，先前講的bbs 架構(gòu)采用的是lvs squid作為前端，這樣的話squidclient 更新緩存時需要更新所有的squid ，這個效率很低下，使用hash 架構(gòu)就可以使squidclient 每次只需要清理一臺squid ，效率大為提升。

2，推薦的是使用nginx 手動hash 架構(gòu)，它可以精確知道鏈接會存在哪臺機器上，這樣就可以配置精確的備份機器。

3 nginx 圖片服務器的架構(gòu)方案

圖片服務通常數(shù)據(jù)容量較大，而且訪問也頻繁，鑒于此，圖片服務就會有兩種問題，一是存儲問題，二是訪問量問題。

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

訪問量也是個大問題，如 果服務不允許防盜鏈，那么訪問量會引起帶寬、服務器壓力等問題，有錢的話直接扔CDN ，沒錢或者有更多的錢，就自己做吧。根據(jù)垣古不變的真理“越老的圖， 訪問量也相對較少”這一點，分成兩大部分，一邊處理最新的圖片，一邊處理老舊的圖片。最新的圖片訪問量大，但存儲量較少；老圖片訪問量低，但存儲量大。

3.1 擬定一個存儲目錄規(guī)則

在現(xiàn)有的/a/b/abcde.jpg這樣的hash 方式下多加一個日期的目錄變成：/200810/16/a/b/abcde.jpg或者/2008/10/16/a/b/abcde.jpg。按日期制定這個目錄規(guī)則后，就可以按年月來拆機器了。

3.2 分機器，分硬盤

按之前的計劃，分成兩個組，一組服務器用lvs 做負載均衡負責新圖片；另一組服務器做舊圖片訪問和備份。新圖機器找?guī)着_好點的服務器，SCSI 硬盤；舊圖機 器沒太大要求，PC 機就行，找夠硬盤就可以，現(xiàn)在IDE 的1T 硬盤也不太貴，最好再搭個raid 就省事了，最主要是這些機器要多。如下圖：

說明一下：

1、圖片服務通過lvs 作為入口，處理能力上還是有保障的。

2、利用nginx 直接對外服務，不必用squid 。

3、圖中的紅線是指主nginx 會將/2006和/2007年的圖片分別代理到兩臺存檔服務器，如果發(fā)現(xiàn)主nginx 的cpu 占用比較大，那么可以考慮使用nginx 的proxy_store將圖片存到主服務器上，定期清理。

4、圖中有一臺存儲分配服務器，作為圖片服務更新圖片的統(tǒng)一入口，有新圖片或者修改圖片的話，由這臺服務器負責將圖片放到正確的服務器上去。

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

6、因為舊數(shù)據(jù)2006和2007年的數(shù)據(jù)基本上是沒有變化的，所以假如硬盤夠大，那么可以把兩年的數(shù)據(jù)合并在一起。

7、如果細心定制，那么舊圖片服務器的硬盤100塞滿是可以的，舊數(shù)據(jù)的容量基本上不會大幅增長，小小預留1-2G 空間就可以了。