1、nginx作為最前端的web cache系統(tǒng)這個結(jié)構(gòu)的優(yōu)點(diǎn)：1、可以使用nginx前端進(jìn)行諸多復(fù)雜的配置，這些配置從前在squid是沒法做或者做起來比較麻煩的，比如針對目錄的防盜鏈。2、nginx前端可以直接轉(zhuǎn)發(fā)部分不需要緩存的請求。3、因為nginx效率高于squid，所以某些情況下可以利用nginx的緩存來減輕squid壓力。4、可以實(shí)現(xiàn)url hash等分配策略。5、可以在最前端開啟gzip壓縮，這樣后面的squid緩存的純粹是無壓縮文檔，可以避免很多無謂的穿透。6、因為nginx穩(wěn)定性比較高，所以lvs不需要經(jīng)常調(diào)整，通過nginx調(diào)整就可以。7、squid的文件打開數(shù)按默認(rèn)的1024

2、就綽綽有余，不過處理的請求可一個都不會少。8、可以啟用nginx的日志功能取代squid，這樣做實(shí)時點(diǎn)擊量統(tǒng)計時可以精確定位到url，不必要再用低效率的grep來過濾。9、因為nginx的負(fù)載能力高于squid，所以在用lvs分流時可以不必分得特別均衡，出現(xiàn)單點(diǎn)故障的幾率比較低。目前這個架構(gòu)還需要更詳盡的測試，當(dāng)前是采用的這個架構(gòu)搭建。nginx和squid配合搭建的web服務(wù)器前端系統(tǒng)這個架構(gòu)是目前比較穩(wěn)妥并且最方便的架構(gòu)，易于多數(shù)人接受：前端的lvs和squid，按照安裝方法，把epoll打開，配置文件照搬，基本上問題不多。這個架構(gòu)和app_squid架構(gòu)的區(qū)別，也是關(guān)鍵點(diǎn)就是：加入了一級

3、中層代理，中層代理的好處實(shí)在太多了：1、gzip壓縮壓縮可以通過nginx做，這樣，后臺應(yīng)用服務(wù)器不管是apache、resin、lighttpd甚至iis或其他古怪服務(wù)器，都不用考慮壓縮的功能問題。2、負(fù)載均衡和故障屏蔽nginx可以作為負(fù)載均衡代理使用，并有故障屏蔽功能，這樣，根據(jù)目錄甚至一個正則表達(dá)式來制定負(fù)載均衡策略變成了小case。3、方便的運(yùn)維管理，在各種情況下可以靈活制訂方案。例如，如果有人用輕量級的ddos穿透squid進(jìn)行攻擊，可以在中層代理想辦法處理掉；訪問量和后臺負(fù)載突變時，可以隨時把一個域名或一個目錄的請求扔入二級cache服務(wù)器；可以很容易地控制no-cache和ex

4、pires等header。等等功能4、權(quán)限清晰這臺機(jī)器就是不寫程序的維護(hù)人員負(fù)責(zé)，程序員一般不需要管理這臺機(jī)器，這樣假如出現(xiàn)故障，很容易能找到正確的人。對于應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器，最好是從維護(hù)人員的視線中消失，我的目標(biāo)是，這些服務(wù)只要能跑得起來就可以了，其它的事情全部可以在外部處理掉。新型的大型bbs架構(gòu)（squid+nginx）這個架構(gòu)基于squid、nginx和lvs等技術(shù)，從架構(gòu)上對bbs進(jìn)行全面優(yōu)化和保護(hù)，有如下特點(diǎn)：1、高性能：所有的點(diǎn)擊基本上全部由前端緩存負(fù)責(zé)，提供最快速的處理。2、高保障度：不需考慮應(yīng)用程序穩(wěn)定與否、程序語言是何種、數(shù)據(jù)庫是何種，都能從架構(gòu)上保證穩(wěn)定。3、高可用

5、性：對應(yīng)用程序的修改達(dá)到最簡化：在程序的某些地方加入清緩存的語句即可，當(dāng)然還需要做頁面靜態(tài)化的工作和統(tǒng)計工作。首先看圖，這個圖比較大：14這個架構(gòu)的特點(diǎn)和一些流程的說明：1、主域名和圖片域名分離域名分離可以使流量分離，緩存策略分離等等，好處諸多。bbs初期一定要做好規(guī)劃，將圖片用另外的域名獨(dú)立服務(wù)，即使沒有足夠機(jī)器，域名也要先分開。另外，圖片服務(wù)器可以使用有別于主域名的另一個域名，一個好處是可以減少讀取cookie對圖片服務(wù)器的壓力，另一個是提高安全性，避免cookie泄露。2、使用LVS作為前端、二級代理和數(shù)據(jù)庫的訪問入口使用LVS作為入口，比其他任何一種方式都來得更優(yōu)質(zhì)。首先LVS的負(fù)載能

6、力很強(qiáng)，因為它工作在網(wǎng)絡(luò)協(xié)議的第4層，使用虛擬ip技術(shù)，所以它本身并不擔(dān)負(fù)任何流量的處理，僅僅是一個封包轉(zhuǎn)發(fā)的功能；第二，LVS的配置相對簡單而且穩(wěn)定，一般去調(diào)整的幾率比較低，也減少了因人為等因素而出現(xiàn)故障；第三，LVS可以處理任何端口的負(fù)載均衡，所以它基本可以做所有服務(wù)的負(fù)載均衡和容錯。在這個架構(gòu)中，除了處理http的80端口之外，LVS也處理了數(shù)據(jù)庫mysql的3306端口，在數(shù)據(jù)庫這個應(yīng)用中是采用的雙機(jī)熱備策略。3、使用nginx+squid作為最前端的緩存組合在這個架構(gòu)中，是最能體現(xiàn)app_nginx_squid_nginx架構(gòu)的優(yōu)勢的。在這個架構(gòu)中的bbs運(yùn)行在緩存上，用戶每發(fā)布一張

7、帖子，都需要使用purge指令清除該帖子的緩存，如果是squid在最前端，那么每次發(fā)布一張?zhí)樱夹枰谒械膕quid中調(diào)用purge指令，這樣在機(jī)器比較多的時候，purge將成為一個巨大的壓力。所以在這里將nginx放在最前端并使用手工url_hash的方式分流，將經(jīng)常需要purge的帖子頁面和列表頁面按一個url對應(yīng)一臺squid的策略，分布到各臺squid上，并提供了一臺或一組backup的squid，個別squid出現(xiàn)異常時將自動使用backup的機(jī)器繼續(xù)提供一段時間的服務(wù)直到其正常。在這樣的架構(gòu)下，purge就不再是關(guān)鍵問題，因為一個url只會對應(yīng)到一臺機(jī)器上，所以purge的時候

8、，后端app_server找到對應(yīng)的機(jī)器就可以了。可以看到在前端中還有一臺nginx(purge)的機(jī)器，這臺機(jī)器是專用于purge的，只要發(fā)送purge指令和需要清除的url到這臺機(jī)器，就可以找到相應(yīng)的服務(wù)器并清除緩存了。另外，purge時還需要清理backup機(jī)器上的緩存，所以無論前端機(jī)器增加到多少，purge指令只會在2臺機(jī)器上執(zhí)行，如果backup機(jī)器使用到2-3臺，purge指令就會在3-4臺機(jī)器上執(zhí)行，仍然在可接受范圍之內(nèi)。nginx作為前端，另有的好處：1) 使用nginx的日志統(tǒng)計點(diǎn)擊量非常方便2) nginx也可作為緩存，一般可以直接負(fù)責(zé)favicon.ico和logo等固定

9、的小圖片4、基于nginx的中層代理nginx中層代理的優(yōu)勢，nginx和squid配合搭建的web服務(wù)器前端系統(tǒng)一節(jié)中有解釋。在這個架構(gòu)中，假如后端的app_server上把帖子頁和列表頁直接生成了靜態(tài)頁面，那么使用中層代理再做一次url_hash，將可以解決后端app_server的硬盤容量的壓力，但是如果使用到url_hash的話，那做容錯就相對麻煩了。所以建議不要采用生成靜態(tài)頁的方式，后端的壓力一般不會非常的大，所以沒有必要生成靜態(tài)頁。假如前端squid的命中率實(shí)在太低下，造成大量穿透，可以考慮使用二級代理暫頂。5、基于LVS的數(shù)據(jù)庫雙機(jī)熱備在這個架構(gòu)中，因為大量的并發(fā)和訪問量都由前端

10、的緩存處理掉了，所以后端的mysql主要壓力來自于數(shù)據(jù)的寫入，所以壓力并不是非常大，并且負(fù)載比較穩(wěn)定，一般不會隨著訪問量上升而提高過快，估計目前一臺64位的機(jī)器，加滿內(nèi)存并使用高速的硬盤，前端負(fù)載數(shù)億訪問量時數(shù)據(jù)庫都不會出現(xiàn)性能問題。在數(shù)據(jù)庫這方面應(yīng)主要考慮故障恢復(fù)，因為數(shù)據(jù)庫崩潰的話，按照一般使用備份恢復(fù)的做法，耗時很長而且難免丟失數(shù)據(jù)，是很棘手的問題。使用雙機(jī)熱備的方案，出現(xiàn)故障時首先可由一臺時刻同步著的備用數(shù)據(jù)庫即刻充當(dāng)主數(shù)據(jù)庫，然后卸下的數(shù)據(jù)庫可以有充分的時間對其進(jìn)行維修，所以是個很安全有效的辦法。當(dāng)然，數(shù)據(jù)庫的優(yōu)化還是要細(xì)心做的，參考：mysql性能的檢查和調(diào)優(yōu)方法細(xì)心地調(diào)一遍，性能

11、會好很多。6、圖片服務(wù)器圖片服務(wù)器在這個架構(gòu)中沒有特別詳細(xì)的介紹，在大型的bbs系統(tǒng)下，圖片常常會出現(xiàn)容災(zāi)現(xiàn)象圖片數(shù)量嚴(yán)重超過了單臺前端服務(wù)器容納能力，導(dǎo)致前端服務(wù)器命中率低下。處理容災(zāi)問題也是非常棘手的，往后會有更詳細(xì)的介紹。7、簡單的點(diǎn)擊量統(tǒng)計辦法1) 1/使用js的script標(biāo)簽訪問另一（臺）組服務(wù)器的空文件，然后定期向數(shù)據(jù)庫更新2) 2/在前端的nginx上直接開啟日志功能，按需要統(tǒng)計點(diǎn)擊量的鏈接規(guī)則進(jìn)行記錄，然后定期更新數(shù)據(jù)庫海量小文件系統(tǒng)架構(gòu)方案現(xiàn)在的網(wǎng)站越做越大了，存儲的東西越來越多，如何解決這些文件存儲也成了新的難題。如果把這些文件都完全采用大硬盤存儲來解決，并不是一個好主意

12、，因為數(shù)據(jù)量越大風(fēng)險就越高，雖然文件能存得下，但是故障率相應(yīng)會較高，另外重建耗費(fèi)時間也比較長。所以最好的辦法是盡可能考慮分布式存儲，把文件想辦法利用網(wǎng)絡(luò)分散到多個機(jī)器上。從所了解的存儲結(jié)構(gòu)來看，分布式存儲大致可以分為幾種：1、類googlefs的分布式文件系統(tǒng)因為目前googlefs沒有開源，所以網(wǎng)上出現(xiàn)的分布式文件系統(tǒng)都是利用google的方案自行實(shí)現(xiàn)的。這個方案的優(yōu)點(diǎn)是可用性比較高，基本上基于硬盤的應(yīng)用都可以處理，可用范圍就比較廣泛。我看了gfs、gfs2、ocfs2、FastDFS、MogileFS的一些相關(guān)介紹，大致有一些認(rèn)識。首先是文檔比較少而出現(xiàn)的問題倒不少；然后是目前這些還沒有一

13、個能稱得上是穩(wěn)定版本，如果有的話，估計也就是其中一些收費(fèi)的版本。因為磁盤存儲乃是致關(guān)重要，所以目前建議還是不要輕易把這些東西部署到重要的地方。假如非常想使用的話，最好是做好充分測試，確保它的功能完全能夠滿足需要；然后還要想辦法在傳統(tǒng)的文件系統(tǒng)中做好完全的備份，以免造成損失。另外可以提的一個東西是memcached，這個東西實(shí)現(xiàn)了內(nèi)存的分布式共享，穩(wěn)定度貌似比以上這些分布式文件系統(tǒng)要穩(wěn)定。不過是完全基于內(nèi)存的，如果數(shù)據(jù)量不是很大，可以一試。2、手工使用文件路徑分散存儲這個結(jié)構(gòu)通常使用在web靜態(tài)文件中，就以這種情形作為例子。如果這些文件數(shù)量比較大，可以通過分散文件路徑，把某個文件的訪問指定到特定

14、的一臺或幾臺服務(wù)器上。例如：1)采用域名的分散策略例如使用2)采用目錄的分散策略假如域名初期并沒有規(guī)劃使用域名策略，那么可以采用代理服務(wù)器來進(jìn)行目錄級的劃分。比如一般存儲大量文件時，因為文件系統(tǒng)的限制以及效率問題，都會按照一定規(guī)則劃分了很多級的目錄，按這些目錄拆分機(jī)器也并不是困難的事情。這種架構(gòu)的問題在于代理服務(wù)器的性能和可靠性問題，需要在這點(diǎn)上稍下一點(diǎn)功夫。以上這兩個方案，都要自行制定策略實(shí)現(xiàn)分散同步傳輸，傳輸一般可以歸納為推送和抓取兩種辦法，同步的話可以采用日志同步（把要同步的數(shù)據(jù)記入日志，通過日志記錄來傳輸相應(yīng)文件）、比較同步（使用rsync等同步軟件）或即時同步（有新的修改就立刻傳輸）

15、；另外要實(shí)現(xiàn)單點(diǎn)故障剔除的話，首先找一個策略把文件存儲到多個節(jié)點(diǎn)上，例如，或目錄a的文件相應(yīng)也存到b和c節(jié)點(diǎn)；然后在環(huán)境中使用故障剔除技術(shù)（lvs或nginx等），就可以解決問題，例如：采用域名的話，可以采用lvs，缺點(diǎn)是使用的機(jī)器就會成倍增加；亦可再用一級代理服務(wù)器，缺點(diǎn)是會犧牲性能。采用目錄的話，因為本身就用到了代理服務(wù)器，所以只要存儲得當(dāng)，實(shí)現(xiàn)比較容易。的系統(tǒng)架構(gòu)研究csdn作為國內(nèi)最大的程序開發(fā)社區(qū)，影響了足足一代人。它是國內(nèi)優(yōu)秀雜志程序員的網(wǎng)站，我從前非常喜歡程序員這本雜志，里面的文章都非常優(yōu)秀，那時只有5元錢的我每個月花10塊錢買本這樣的雜志，看個三五年，都舍不得丟下。但是今天觀察

16、了下csdn站點(diǎn)的架構(gòu)，發(fā)現(xiàn)做的比較簡單，看來開發(fā)者比較喜歡從程序著手，著重優(yōu)化代碼和數(shù)據(jù)庫，對系統(tǒng)整體架構(gòu)思考的時間不多。我著重看了幾個二級域名：www、news、bbs/community和blog，其中www、news這些靜態(tài)文件都有通過squid緩存，用的app_squid架構(gòu)，然后是dns輪詢做分流。在這里順便討論下為什么很多大型網(wǎng)站都喜歡用dns輪詢來作首頁，而不采用lvs或其它負(fù)載均衡策略。這是因為負(fù)載均衡都是把所有的訪問先集中到一個ip上，因為只有一個ip，所以無意間這個ip的穩(wěn)定性就關(guān)系重大了。ip穩(wěn)定性會受很多因素影響：n個交換機(jī)、線路、機(jī)器等等，頗為復(fù)雜。而首頁很有可能會

17、用到異地的負(fù)載均衡，這么來不用dns，方案就很難設(shè)計了。現(xiàn)在的常用瀏覽器和下載軟件，都有對dns的故障處理機(jī)制，所以dns也是可以屏蔽掉一些故障的，雖然功能不強(qiáng)，但也較為實(shí)用；相比之下，即使是lvs也會有很多雜七雜八的問題，反而不如dns性能強(qiáng)和穩(wěn)定。csdn靜態(tài)頁前端緩存（2009-05-11)：Address: 21Address: 22Address: 23Address: 24這四臺機(jī)器squid版本：2.6.STABLE14，能夠揪出很多問題來：1) 從文件打開數(shù)可見編譯參數(shù)都是不同的，或

18、是系統(tǒng)配置參數(shù)不同？機(jī)器分了兩批上線吧。2) 居然沒有編譯開啟epoll，性能看來好不了，重新編譯下吧。3) 緩存沒有細(xì)致調(diào)優(yōu)，所以這幾臺機(jī)的命中率很低，大量穿透，我估計是重啟squid的時候沒有清理緩存文件夾造成。4) 很多內(nèi)容都沒有expires頭，這也不能算什么問題，穩(wěn)定就好，IIs要細(xì)致定義expires也很麻煩。5) 這些靜態(tài)頁面都不支持gzip壓縮，浪費(fèi)了不少帶寬，此問題應(yīng)歸罪于IIs和squid的配合問題，可加nginx中層代理處理它。由此可見csdn的系統(tǒng)管理員對系統(tǒng)都不太上心，從另一個角度講，系統(tǒng)嘛stable就好，管它優(yōu)不優(yōu)化，我覺得這個心態(tài)也非常贊。有興趣可以參考：這篇文

19、章，然后用：Squidclient -p80 - mgr:info看下。blog和community這兩個多數(shù)是動態(tài)頁面，csdn沒有作靜態(tài)化處理，所以就沒有緩存，直接去了后臺，最近其增加了nginx，使用nginx來作負(fù)載均衡。在nginx后面有多少臺IIs，不能探得出來，回想起從前csdn那非常不穩(wěn)定的狀態(tài)，加了個nginx確實(shí)好了很多，由于使用了nginx，所以這兩個系統(tǒng)支持壓縮就變得順理成章。bbs沒有使用緩存也都說得過去，但像blog這樣的系統(tǒng)，都沒有使用緩存，覺得非常遺憾，事實(shí)上這兩個系統(tǒng)都可以用squid完全緩存，csdn從此就可以非常穩(wěn)定了，但前面也提到了，開發(fā)者通常喜歡從自己

20、寫的代碼里著手優(yōu)化，這是思維上的局限性，我自己也花了好多年才跳出這個框框，明白了系統(tǒng)優(yōu)化要從整體入手這么條簡單的道理。csdn使用nginx來負(fù)載均衡，也是有所領(lǐng)悟，希望他們能更放得開，更為進(jìn)步。我希望我喜歡的網(wǎng)站都非常穩(wěn)定快速，這樣我在網(wǎng)上閑逛的時候會更順心些，像csdn、天涯和網(wǎng)易評論這些東東我都是非常之恨的，不過他們都在進(jìn)步，算是好事。因為csdn的前端架構(gòu)太簡單，所以圖我也懶得畫了，事實(shí)上估計csdn也不是簡單的東西，好多邏輯都被藏在代碼和數(shù)據(jù)庫那頭，這不可得知。因為csdn代碼層使用的是windows主機(jī)和，既然使用了windows，那么棘手的事肯定不會少，還是要找更好的前端，把這些

21、app服務(wù)器蓋得嚴(yán)嚴(yán)實(shí)實(shí)為妙，稍有疏漏的話恢復(fù)服務(wù)的時間就長了。對新架構(gòu)的嘗試先看看架構(gòu)圖：實(shí)際上是app_nginx_squid_nginx的結(jié)構(gòu)，nginx頂在最前面，具體有多少臺我就不通告了，然后后面有比nginx更多的squid。這個架構(gòu)的特點(diǎn)是擴(kuò)展了squid的功能，并且可以將很多請求繞過squid，實(shí)際應(yīng)用時仍然出現(xiàn)一點(diǎn)問題，并在此系統(tǒng)的超級負(fù)荷下收獲了不少經(jīng)驗。為保商業(yè)秘密，只能告訴一個大概數(shù)字，此系統(tǒng)帶圖片的負(fù)荷每日在2億-5億之間，nginx代理全部機(jī)器加起來每秒處理的并發(fā)數(shù)日常總共是10000左右。另說說每秒并發(fā)如何計算，跟據(jù)測試和對比，在web最前端每秒并發(fā)=系統(tǒng)的est

22、ablished/web server的keep alive。如果不是前端，那就不那么好算了，在這個系統(tǒng)中squid的established極低，不到10個，所以鐵定不能從這個數(shù)字去判斷了，可以使用squid的mgr:info來查看。在這樣的負(fù)荷下工作，平常運(yùn)行時是沒有很大的問題，就是在爆發(fā)地震性新聞那一小段時間難于招架。于是我檢查了系統(tǒng)，發(fā)現(xiàn)幾個問題，并相應(yīng)對系統(tǒng)進(jìn)行了優(yōu)化：1、調(diào)整nginx的超時設(shè)置我一般都會把nginx的超時時間設(shè)得稍微長一些，免得會拋出504錯誤，所以一般設(shè)為5分鐘，但是在高負(fù)荷下，nginx總是能探測到很多的超時，經(jīng)過測試，因為nginx前端堆積過多這些超時的請求，

23、所以nginx的cpu占用率會上漲，最后nginx前端負(fù)荷過高，但后面一級的squid應(yīng)該也負(fù)荷同樣多的超時請求，但它卻好得很。這樣看來，nginx代理在處理這些超時請求上還有待提高。所以我調(diào)整了超時設(shè)置，將超時限定為5秒，這下負(fù)載就下來了不少。因為nginx超時后會重新選擇一個后端請求，所以對訪問影響不大，客戶端同時也不會在一個超時請求下等待過長時間，這樣就更為友好。2、將圖片用nginx緩存鑒于nginx代理會出現(xiàn)問題，干脆把修改率不大的圖片用nginx緩存起來，直接對外訪問好了。于是使用proxy_store配置了一下，圖片放到/dev/shm內(nèi)存里，然后寫一個shell每小時把這些圖片

24、全刪掉重取。放在內(nèi)存里刪除文件那是快啊，那么多圖片一閃就刪完了。這樣做下來，nginx的負(fù)載就很低了，處理同樣的并發(fā)量，load average從2直降到了0.2，這時我覺得甚至只用單臺nginx都可以工作。ps:在實(shí)際應(yīng)用中也嘗試了nginx的url hash模塊，發(fā)現(xiàn)這個模塊在有squid當(dāng)機(jī)時，它并不會自動切換到另一臺，就這個問題看來這個模塊暫時還是不好使。天涯bbs系統(tǒng)架構(gòu)分析研究，就先從入口開始。天涯所使用的ip地址54 海南網(wǎng)通54 湖南電信51 海南電信這些ip估計是天涯用來分流帶寬所使用，在我測試的這個時間

25、，51這個ip有可能正在遷移到54。接下來是四臺一組的squid主機(jī)（squid/2.6.STABLE4）每組負(fù)責(zé)幾個板塊，統(tǒng)計了一下至少有3組，也就是12臺 。一組稱之通用，一組稱之熱門，一組可稱之新來的。這些squid組要做到url分流，那么肯定得有一個7層代理拉，根據(jù)天涯之前的記錄，這個7層代理是F5。其它看了一下，天涯所有的域名、流量和并發(fā)量基本上都是通過這兩三臺F5搞定的，看來F5的能力還是比較強(qiáng)的。不過，抄句話來說就是光喝還沒醉過。然后cache下來就是web主機(jī)了，天涯用的是非常流行的windows 2000和Microsoft I

26、IS 5，主機(jī)數(shù)量根據(jù)cache組計應(yīng)該會有3 臺。會不會闊綽的用到3 臺sql server不得而知，數(shù)據(jù)庫裝在web服務(wù)器上的可能性比較高。另外有些板塊是不走cache服務(wù)器的，那些也會用到機(jī)器，這些機(jī)器是不是重復(fù)利用的，以后有空再慢慢統(tǒng)計。另外天涯還有兩個項目，一下還想不起名字，那兩個是google提供的完整方案。天涯的程序大部分是asp，有部分是，有一部分又是resin跑的jsp。在bbs中，估計是大部分用的asp，然后在幾個關(guān)鍵點(diǎn)用jsp來補(bǔ)充，也就是asp jsp的結(jié)構(gòu)，變幻多端，不可學(xué)也。IIS6我已經(jīng)5年沒有實(shí)用過了，就不加評說。resin的性能不錯，不過還不能算穩(wěn)定服務(wù)器。s

27、ql server我也多年未用，不過當(dāng)年我非常的菜，用著這玩意非常不順，現(xiàn)在我還是非常之菜，偶爾碰到同樣感到頭疼。畫個架構(gòu)圖送大家收藏吧。nginx圖片服務(wù)器的架構(gòu)方案圖片服務(wù)通常數(shù)據(jù)容量較大，而且訪問也頻繁，鑒于此，圖片服務(wù)就會有兩種問題，一是存儲問題，二是訪問量問題。存儲問題就是硬盤容量問題，花錢買硬盤就可以了，看似簡單，但著實(shí)也是最苦的問題。按目前探索來看，最好的方式是：在任何時刻遇到硬盤空間不夠時，買顆硬盤插上，最多改改配置，就能立刻利用；另外，硬盤要能充分利用，不然圖片存儲量大再加上備份，很恐怖，最好是每顆硬盤都用上100%的空間。訪問量也是個大問題，如果服務(wù)不允許防盜鏈，那么訪問量

28、會引起帶寬、服務(wù)器壓力等問題，有錢的話直接扔CDN，沒錢或者有更多的錢，就自己做吧。根據(jù)垣古不變的真理“越老的圖，訪問量也相對較少”這一點(diǎn)，分成兩大部分，一邊處理最新的圖片，一邊處理老舊的圖片。最新的圖片訪問量大，但存儲量較少；老圖片訪問量低，但存儲量大。大概分析完了，開始制定方案。一、擬定一個存儲目錄規(guī)則：在現(xiàn)有的/a/b/abcde.jpg這樣的hash方式下多加一個日期的目錄變成：/200810/16/a/b/abcde.jpg或者/2008/10/16/a/b/abcde.jpg。按日期制定這個目錄規(guī)則后，就可以按年月來拆機(jī)器了。二、分機(jī)器，分硬盤按之前的計劃，分成兩個組，一組服務(wù)器用

29、lvs做負(fù)載均衡負(fù)責(zé)新圖片；另一組服務(wù)器做舊圖片訪問和備份。新圖機(jī)器找?guī)着_好點(diǎn)的服務(wù)器，SCSI硬盤；舊圖機(jī)器沒太大要求，PC機(jī)就行，找夠硬盤就可以，現(xiàn)在IDE的1T硬盤也不太貴，最好再搭個raid就省事了，最主要是這些機(jī)器要多。照這個圖，搭一搭說明一下：1. 圖片服務(wù)通過lvs作為入口，處理能力上還是有保障的。2. 利用nginx直接對外服務(wù)，不必用squid。3. 圖中的紅線是指主nginx會將/2006和/2007年的圖片分別代理到兩臺存檔服務(wù)器，如果發(fā)現(xiàn)主nginx的cpu占用比較大，那么可以考慮使用nginx的proxy_store將圖片存到主服務(wù)器上，定期清理。4. 圖中有一臺存儲

30、分配服務(wù)器，作為圖片服務(wù)更新圖片的統(tǒng)一入口，有新圖片或者修改圖片的話，由這臺服務(wù)器負(fù)責(zé)將圖片放到正確的服務(wù)器上去。5. 舊圖片服務(wù)器當(dāng)前用年份來劃分，每年增加兩臺服務(wù)器，亦可是加兩塊硬盤，注意，不要相信raid，一定要有兩臺機(jī)器，地理上分在兩個城市則更好。6. 因為舊數(shù)據(jù)2006和2007年的數(shù)據(jù)基本上是沒有變化的，所以假如硬盤夠大，那么可以把兩年的數(shù)據(jù)合并在一起。7. 如果細(xì)心定制，那么舊圖片服務(wù)器的硬盤100%塞滿是可以的，舊數(shù)據(jù)的容量基本上不會大幅增長，小小預(yù)留1-2G空間就可以了。使用這個架構(gòu)的話，到了2009年，我會把2008年的數(shù)據(jù)想辦法遷到舊圖服務(wù)器上，硬盤不夠的話，加硬盤就可以了。如果圖片量實(shí)在太大，主服務(wù)器連一年的數(shù)據(jù)都裝不下，那可以用啟用月份來劃分；如果一個月都裝不下了，那也太夸張了，那就啟用日期吧；如果一天的數(shù)據(jù)都裝不下，那就￥。網(wǎng)站系統(tǒng)二級緩存架構(gòu)應(yīng)用架構(gòu)圖示：1、合并穿透當(dāng)前端一級緩存采用了兩臺以上的squid后，同一個訪問量較大的鏈接，假設(shè)其三分鐘更新一次，每臺squid就會每三分鐘向后臺發(fā)送一個請求更新這個鏈接，那么很顯然兩臺