圖片服務(wù)器分別介紹現(xiàn)在很多的網(wǎng)站上都會(huì)用到大量的圖片，而圖片是網(wǎng)頁(yè)傳輸中占主要的數(shù)據(jù)量,也是影響網(wǎng)站性能的主要因素。因此很多網(wǎng)站都會(huì)將圖片存儲(chǔ)從網(wǎng)站中分別出來，另外架構(gòu)一個(gè)或多個(gè)服務(wù)器來存儲(chǔ)圖片，將圖片放到一個(gè)虛擬書目中，而網(wǎng)頁(yè)上的圖片都用一個(gè)URL地址來指向這些服務(wù)器上的圖片的地址，這樣的話網(wǎng)站的性能就明顯提高了，圖片服務(wù)器(ImageServer)的概念也就產(chǎn)生了。圖片服務(wù)器的優(yōu)勢(shì)分擔(dān)Web服務(wù)器的I/O負(fù)載-將耗費(fèi)資源的圖片服務(wù)分別出來，提高服務(wù)器的性能和穩(wěn)定性。能夠特地對(duì)圖片服務(wù)器進(jìn)行優(yōu)化-為圖片服務(wù)設(shè)置有針對(duì)性的緩存方案，削減帶寬成本，提高訪問速度。提高網(wǎng)站的可擴(kuò)展性-通過增加圖片服務(wù)器，提高圖片吞吐實(shí)力。圖片服務(wù)器的留意事項(xiàng)選擇適合圖片存儲(chǔ)的物理介質(zhì)和文件系統(tǒng)運(yùn)用物理上獨(dú)立的服務(wù)器假如擁有多臺(tái)圖片服務(wù)器，要考慮服務(wù)器之間的圖片同步問題運(yùn)用獨(dú)立域名制定合理的緩存策略運(yùn)用圖片處理模塊對(duì)用戶上傳的圖片進(jìn)行再加工圖片服務(wù)器的架構(gòu)圖片是網(wǎng)站中必不行少的一個(gè)組成部分，隨著網(wǎng)站的不斷發(fā)展，對(duì)圖片的處理也將隨著訪問的增長(zhǎng)，圖片的增加提出不斷改進(jìn)的需求，網(wǎng)站初期，全部的一切都從簡(jiǎn)圖片所存在的位置通常會(huì)在站點(diǎn)下的Images文件夾。隨著訪問的增加，IIS壓力的增大，起先做拆分，將圖片文件夾作為單獨(dú)站點(diǎn)提取出來如://images.***/(可能依據(jù)須要會(huì)拆分成多個(gè)圖片服務(wù)器，與詳細(xì)業(yè)務(wù)環(huán)境相關(guān))，拆分之后很好的將單個(gè)IIS應(yīng)用池的壓力分擔(dān)到2個(gè)乃至多個(gè)上，大大提高訪問瓶頸。隨著訪問的進(jìn)一步增加，服務(wù)器壓力已經(jīng)無法支撐，這時(shí)我們須要將圖片站點(diǎn)作為獨(dú)立服務(wù)器存在。在訪問圖片的過程中，我們可能會(huì)面臨一個(gè)圖片有多個(gè)圖片尺寸的需求，前期我們通常會(huì)在保存頁(yè)面的過程中保存我們須要的各個(gè)尺寸圖片，但隨著所需尺寸的不同，保存圖片時(shí)須要的尺寸越來越多，這時(shí)我們?nèi)绾螒?yīng)對(duì)？IIS服務(wù)器的并發(fā)訪問意味著隨著用戶的進(jìn)一步增加，我們單臺(tái)圖片服務(wù)器已經(jīng)不足以應(yīng)對(duì)了，此時(shí)我們?nèi)绾芜M(jìn)一步擴(kuò)展？如上圖所示，我們此時(shí)可針對(duì)這兩個(gè)問題做出統(tǒng)一解決方案，在前端添加squid緩存服務(wù)器，添加一臺(tái)或者多臺(tái)動(dòng)態(tài)切圖服務(wù)器。Squid或者Nginx代理緩存服務(wù)器能夠極大的提升圖片系統(tǒng)的并發(fā)訪問，使系統(tǒng)突破現(xiàn)有限制。動(dòng)態(tài)切圖服務(wù)器主要的作用是針對(duì)不同尺寸的圖片訪問調(diào)取原圖臨時(shí)生成符合需求的圖片并返回。原圖的存儲(chǔ)區(qū)可以與圖片服務(wù)放在一起，也可以講圖片放于單獨(dú)的服務(wù)器上。在此種結(jié)構(gòu)中，并發(fā)的最大訪問限制將是squid或者其他代理服務(wù)器的系統(tǒng)瓶頸，當(dāng)切圖服務(wù)壓力增大時(shí)，只需添加相應(yīng)切圖服務(wù)器即可，圖片存儲(chǔ)區(qū)的增長(zhǎng)也可通過添加硬盤或者服務(wù)器進(jìn)行解決。假如您的站點(diǎn)訪問量還在進(jìn)一步增長(zhǎng)，squid的訪問瓶頸即將被突破，這時(shí)我們又該如何應(yīng)對(duì)呢？如上圖所示，采納多臺(tái)Squid或Nginx服務(wù)器，在前端添加F5或LVS負(fù)載均衡(同時(shí)還可開啟緩存功能)。此時(shí)將極大提升訪問的并發(fā)量，可以依據(jù)狀況隨時(shí)調(diào)配服務(wù)器。當(dāng)然此時(shí)也存在肯定的瑕疵，那就是可能在多臺(tái)Squid上存在同一張圖片，因?yàn)樵L問圖片時(shí)可能第一次分到squid1，在F5過期后其次次訪問到squid2或者別的，當(dāng)然相對(duì)并發(fā)問題的解決，此種少量的冗余完全在我們的允許范圍之內(nèi)。在做了這很多的工作后，假如條件允許對(duì)圖片服務(wù)器做下CDN，那將會(huì)對(duì)您站點(diǎn)的圖片訪問質(zhì)量有更大的提升。圖片存儲(chǔ)架構(gòu)部署獨(dú)立圖片服務(wù)器的必要性我們知道，無論對(duì)于Apache還是IIS，圖片始終是最消耗系統(tǒng)資源的，假如將圖片服務(wù)和應(yīng)用服務(wù)放在同一個(gè)服務(wù)器的話，應(yīng)用服務(wù)器很簡(jiǎn)潔會(huì)因?yàn)閳D片的高I/O負(fù)載而崩潰，因此對(duì)于有些大型網(wǎng)站項(xiàng)目，我們有必要將圖片服務(wù)器和應(yīng)用服務(wù)器分別。部署獨(dú)立的圖片服務(wù)器（甚至是服務(wù)器集群）是大型網(wǎng)站圖片存儲(chǔ)解決方案中最基礎(chǔ)的，因?yàn)橛辛霜?dú)立的圖片服務(wù)器后，我們才能對(duì)圖片服務(wù)器做更有針對(duì)性的性能優(yōu)化，比如從硬件角度說，圖片服務(wù)器可以配置高端的硬盤，7200轉(zhuǎn)的換成15000轉(zhuǎn)的，而CPU卻只要一般就可以了；從軟件角度說，可以為圖片服務(wù)器配置特別的文件系統(tǒng)來滿意對(duì)圖片的I/O懇求，如淘寶的TFS，就很好地解決了大規(guī)模小圖片文件帶來的I/O噩夢(mèng)，同時(shí)，我們也可以采納nginx、squid來代理圖片懇求等等。采納獨(dú)立域名留意，這里是指獨(dú)立域名，不是子域哦，比如yahoo圖片服務(wù)器用了yimg的域名，而不是用二級(jí)域名img.yahoo，這是為什么呢？個(gè)人覺得緣由主要有以下幾點(diǎn)：1、同一域名下閱讀器的并發(fā)連接數(shù)有限制，一般在2-6之間，下圖列舉了各個(gè)閱讀器的并發(fā)連接數(shù)（下圖供參考）這樣，我們假如給圖片服務(wù)器配置獨(dú)立的域名，那么在一個(gè)頁(yè)面中加載圖片時(shí)，就可以突破閱讀器連接數(shù)的限制，理論上，增加一個(gè)獨(dú)立域名，并發(fā)連接數(shù)加倍。2、由于cookie的緣由，對(duì)緩存不利比如有一張圖片://test/img/xx.gif，那么當(dāng)我們向它發(fā)起懇求的時(shí)候，會(huì)帶上test域名下的cookie，由于大部分webcache都只緩存不帶cookie的懇求，這樣就導(dǎo)致每次的圖片懇求都不能命中cache，而照舊要去原始服務(wù)器獲得圖片，導(dǎo)致圖片緩存意義不大。所以，還是給單獨(dú)搞一個(gè)圖片獨(dú)立域名吧，當(dāng)然，不只是圖片，css和js文件也可以參照這個(gè)思路來搞。3、便利CDN同步圖片服務(wù)器分別后，如何進(jìn)行圖片上傳和圖片同步當(dāng)然任何事物都具有兩面性，圖片服務(wù)器分別當(dāng)然提升了圖片訪問的效率，大大緩解了服務(wù)器因圖片造成的I/O瓶頸，但是分別以后圖片的上傳和同步就成了一個(gè)大問題了。下面就我個(gè)人的想法談?wù)剮追N解決方案。1、NFS共享方式假如你不想在每臺(tái)圖片服務(wù)器同步全部圖片，那NFS共享是最簡(jiǎn)潔也最好用的方式。NFS是個(gè)分布式的客戶機(jī)/服務(wù)器文件系統(tǒng)，NFS的實(shí)質(zhì)在于用戶間計(jì)算機(jī)的共享，用戶可以聯(lián)結(jié)到共享計(jì)算機(jī)并象訪問本地硬盤一樣訪問共享計(jì)算機(jī)上的文件。詳細(xì)實(shí)現(xiàn)思路是：web服務(wù)器通過nfs掛載多臺(tái)圖片服務(wù)器export出來的書目，用戶先將圖片上傳到web服務(wù)器，然后將上傳的圖片通過程序拷貝到這個(gè)mount書目中去，這樣那幾臺(tái)圖片服務(wù)器就也能訪問到剛上傳的圖片了（留意，只是共享了，并沒有真正拷貝到圖片服務(wù)器）。再給那幾臺(tái)圖片服務(wù)器綁定獨(dú)立域名，于是閱讀器端就可以用單獨(dú)的域名來訪問圖片了。這種方式基本不會(huì)有因同步造成的延時(shí)，但須要依靠nfs，nfs掛掉會(huì)影響web服務(wù)器。如下圖至于如何配置nfs，大家google一下，或者看一下這篇文章，是在Linux下配置NFS的2、利用FTP同步和上面nfs不一樣的是，用戶上傳完圖片后是利用ftp同步到各個(gè)圖片服務(wù)器的，php、java、基本上都能操作ftp。這樣的話每個(gè)圖片服務(wù)器就都保存一份圖片的副本，也起到了備份的作用。但是缺點(diǎn)是將圖片ftp到服務(wù)器比較耗時(shí)，假如異步去同步的話又會(huì)有延時(shí)，不過一般的小圖片文件也還好了。圖片服務(wù)器的URLHASH架構(gòu)剖析什么是urlhash架構(gòu)urlhash架構(gòu)對(duì)url進(jìn)行一次hash算法，然后通過hash結(jié)果找到對(duì)應(yīng)的服務(wù)器。因?yàn)獒槍?duì)單一個(gè)url的hash結(jié)果是一樣的，所以理論上這個(gè)url會(huì)被永久安排到固定的一臺(tái)服務(wù)器上。另外因?yàn)榻?jīng)過了hash算法，所以安排url就很勻稱，同時(shí)訪問量也可以達(dá)到均衡。為什么要用urlhash架構(gòu)1,圖片服務(wù)器的特點(diǎn)一是訪問量很大，二是容量也很大，通過簡(jiǎn)潔的負(fù)載均衡，可以解決訪問量大的問題，但是容量的問題并沒有改善。所以會(huì)造成容災(zāi)問題。2,容災(zāi)問題：系統(tǒng)某個(gè)時(shí)間段被訪問的數(shù)據(jù)嚴(yán)峻超出緩存集群中最小單機(jī)的容納容量就會(huì)造成容災(zāi)，容災(zāi)會(huì)使大量單一鏈接穿透，干脆對(duì)后臺(tái)的IO性能影響很大。3,雖然可以通過增加緩存容量的配置來解決容災(zāi)問題，但是內(nèi)存總是有限的，為每一臺(tái)機(jī)器增加超大內(nèi)存成本上也開銷很大，另外在squid中也不宜配置很大的磁盤緩存，否則squid中的hash表會(huì)很大，性能很差。4,通過hash架構(gòu)，可以充分利用緩存集群的內(nèi)存，容災(zāi)問題就不再取決于緩存集群中最小單機(jī)的容納容量，而是緩存集群中全部機(jī)器的容納容量之和。各種urlhash架構(gòu)1）基于dns的hash架構(gòu)。2）基于nginx的自動(dòng)hash架構(gòu)。3）基于nginx的手動(dòng)hash架構(gòu)?；赿ns的hash架構(gòu)dns的hash架構(gòu)圖dns的hash架構(gòu)說明這個(gè)架構(gòu)適合面對(duì)用戶的圖片系統(tǒng)，比如論壇、相冊(cè)、博客中的圖片上傳。這樣它才能夠保證文件名有一樣的規(guī)范。這個(gè)架構(gòu)圖分了36個(gè)域名，圖片文件名是用md5值起的，在md5值中取一位字母就可以表明它是在哪個(gè)域名里，域名就對(duì)應(yīng)了機(jī)器，上傳分發(fā)的時(shí)候也是依據(jù)此字母來分發(fā)。dns的hash架構(gòu)的優(yōu)缺點(diǎn)優(yōu)點(diǎn)：1）運(yùn)用了dns分流，成本較低，而且dns性能高，不用維護(hù)。2）可突破IE默認(rèn)每主機(jī)2個(gè)線程的限制。缺點(diǎn)：1）可用性方面，假如有一臺(tái)機(jī)器宕機(jī)，則指向這臺(tái)機(jī)器的懇求無法讀取。2）分流方面，只能全部同步，成本較高3）只適用于面對(duì)用戶的系統(tǒng)基于nginx的自動(dòng)手動(dòng)hash架構(gòu)nginx的自動(dòng)hash架構(gòu)圖nginx的自動(dòng)hash架構(gòu)說明1,這是一種新的緩存架構(gòu)，由nginx作為最前端，代理到緩存機(jī)器。2,nginx后面是緩存組，由nginx經(jīng)過urlhash后將懇求分到緩存機(jī)器。3,這個(gè)架構(gòu)便利純squid緩存升級(jí)，可以在squid的機(jī)器上加裝nginx。4,nginx有緩存的功能，可以將一些訪問量特大的鏈接干脆緩存在nginx上，就不用經(jīng)過多一次代理的懇求。比如favicon.ico和網(wǎng)站的logo。nginx的自動(dòng)hash架構(gòu)優(yōu)缺點(diǎn)優(yōu)點(diǎn)1）高性能2）運(yùn)用便利，后臺(tái)是什么樣關(guān)系不大3）有很高的可用性4）緩存架構(gòu)，分流便利5）可干脆在nginx代理緩存部分鏈接缺點(diǎn)url分流可控性弱，增減緩存機(jī)器都會(huì)引起緩存重新安排，意味著緩存全部失效。nginx的手動(dòng)hash架構(gòu)說明1，這個(gè)架構(gòu)圖和自動(dòng)hash的架構(gòu)是一樣的，唯一有差別的是hash算法的改變，自動(dòng)hash是用nginxupstreamhash模塊自帶的hash算法來實(shí)現(xiàn)分流，這個(gè)手動(dòng)架構(gòu)是自己設(shè)計(jì)一個(gè)算法來實(shí)現(xiàn)。2，算法設(shè)計(jì)思路是從url中取一個(gè)字符來作分流依據(jù)，比如定義鏈接的倒數(shù)第10個(gè)字符來分流，同樣可以安排得很勻稱。3，手動(dòng)架構(gòu)可以避開自動(dòng)架構(gòu)中增減機(jī)器帶來的緩存失效問題，另外可以精確知道一個(gè)鏈接究竟存在哪臺(tái)緩存上。nginx的手動(dòng)hash架構(gòu)優(yōu)缺點(diǎn)優(yōu)點(diǎn)1）基本可以繼承自動(dòng)架構(gòu)的優(yōu)點(diǎn)2）避開增減機(jī)器的問題3）精確知道鏈接存儲(chǔ)在哪臺(tái)緩存上缺點(diǎn)配置較困難，要安排勻稱配置不易。采納Hash架構(gòu)對(duì)bbs架構(gòu)優(yōu)化1，從前講的bbs架構(gòu)采納的是lvs+squid作為前端，這樣的話squidclient更新緩存時(shí)須要更新全部的squid，這個(gè)效率很低下，運(yùn)用hash架構(gòu)就可以使squidclient每次只須要清理一臺(tái)squid，效率大為提升。2，舉薦的是運(yùn)用nginx手動(dòng)hash架構(gòu)，它可以精確知道鏈接會(huì)存在哪臺(tái)機(jī)器上，這樣就可以配置精確的備份機(jī)器。nginx圖片服務(wù)器的架構(gòu)方案圖片服務(wù)通常數(shù)據(jù)容量較大，而且訪問也頻繁，鑒于此，圖片服務(wù)就會(huì)有兩種問題，一是存儲(chǔ)問題，二是訪問量問題。

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

訪問量也是個(gè)大問題，如果服務(wù)不允許防盜鏈，那么訪問量會(huì)引起帶寬、服務(wù)器壓力等問題，有錢的話干脆扔CDN，沒錢或者有更多的錢，就自己做吧。依據(jù)垣古不變的真理“越老的圖，訪問量也相對(duì)較少”這一點(diǎn)，分成兩大部分，一邊處理最新的圖片，一邊處理老舊的圖片。最新的圖片訪問量大，但存儲(chǔ)量較少；老圖片訪問量低，但存儲(chǔ)量大。擬定一個(gè)存儲(chǔ)書目規(guī)則在現(xiàn)有的/a/b/abcde.jpg這樣的hash方式下多加一個(gè)日期的書目變成：/200810/16/a/b/abcde.jpg或者/2008/10/16/a/b/abcde.jpg。按日期制定這個(gè)書目規(guī)則后，就可以按年月來拆機(jī)器了。分機(jī)器，分硬盤按之前的安排，分成兩個(gè)組，一組服務(wù)器用lvs做負(fù)載均衡負(fù)責(zé)新圖片；另一組服務(wù)器做舊圖片訪問和備份。新圖機(jī)器找?guī)着_(tái)好點(diǎn)的服務(wù)器，SCSI硬盤；舊圖機(jī)器沒太大要求，PC機(jī)就行，找夠硬盤就可以，現(xiàn)在IDE的1T硬盤也不太貴，最好再搭個(gè)raid就省事了，最主要是這些機(jī)器要多。如下圖：說明一下：

1、圖片服務(wù)通過lvs作為入口，處理實(shí)力上還是有保障的。

2、利用nginx干脆對(duì)外服務(wù)，不必用squid。

3、圖中的紅線是指主nginx會(huì)將/2006和/2007年的圖片分別代理到兩臺(tái)存檔服務(wù)器，假如發(fā)覺主nginx的cpu占用比較大，那么可以考慮運(yùn)用nginx的pr