Nginx squid架構(gòu)的特點(diǎn)和一些流程的在很多人看來還是有些疑惑的，其實(shí)我們?cè)谑褂弥羞€是有不少的技巧可以掌握的。下面我們就來看看有關(guān)Nginx squid架構(gòu)的相關(guān)流程介紹。

1、主域名和圖片域名分離

域名分離可以使流量分離，緩存策略分離等等，好處諸多。bbs初期一定要做好規(guī)劃，將圖片用另外的域名獨(dú)立服務(wù)，即使沒有足夠機(jī)器，域名也要先分開。另外，圖片服務(wù)器可以使用有別于主域名的另一個(gè)域名，一個(gè)好處是可以減少讀取cookie對(duì)圖片服務(wù)器的壓力，另一個(gè)是提高安全性，避免cookie泄露。#t#

2、使用LVS作為前端、二級(jí)代理和數(shù)據(jù)庫(kù)的訪問入口

使用LVS作為入口，比其他任何一種方式都來得更優(yōu)質(zhì)。首先LVS的負(fù)載能力很強(qiáng)，因?yàn)樗ぷ髟诰W(wǎng)絡(luò)協(xié)議的第4層，使用虛擬ip技術(shù)，所以它本身并不擔(dān)負(fù)任何流量的處理，僅僅是一個(gè)封包轉(zhuǎn)發(fā)的功能；第二，LVS的配置相對(duì)簡(jiǎn)單而且穩(wěn)定，一般去調(diào)整的幾率比較低，也減少了因人為等因素而出現(xiàn)故障；第三，LVS可以處理任何端口的負(fù)載均衡，所以它基本可以做所有服務(wù)的負(fù)載均衡和容錯(cuò)。在這個(gè)架構(gòu)中，除了處理http的80端口之外，LVS也處理了數(shù)據(jù)庫(kù)mysql的3306端口，在數(shù)據(jù)庫(kù)這個(gè)應(yīng)用中是采用的雙機(jī)熱備策略。

3、使用Nginx squid架構(gòu)作為最前端的緩存組合

在這個(gè)架構(gòu)中，是最能體現(xiàn)app_Nginx_squid_Nginx架構(gòu)的優(yōu)勢(shì)的。在這個(gè)架構(gòu)中的bbs運(yùn)行在緩存上，用戶每發(fā)布一張?zhí)樱夹枰褂胮urge指令清除該帖子的緩存，如果是squid在最前端，那么每次發(fā)布一張?zhí)樱夹枰谒械膕quid中調(diào)用purge指令，這樣在機(jī)器比較多的時(shí)候，purge將成為一個(gè)巨大的壓力。

所以在這里將Nginx squid架構(gòu)放在最前端并使用手工url_hash的方式分流，將經(jīng)常需要purge的帖子頁(yè)面和列表頁(yè)面按一個(gè)url對(duì)應(yīng)一臺(tái)squid的策略，分布到各臺(tái)squid上，并提供了一臺(tái)或一組backup的squid，個(gè)別squid出現(xiàn)異常時(shí)將自動(dòng)使用backup的機(jī)器繼續(xù)提供一段時(shí)間的服務(wù)直到其正常。在這樣的架構(gòu)下，purge就不再是關(guān)鍵問題，因?yàn)橐粋€(gè)url只會(huì)對(duì)應(yīng)到一臺(tái)機(jī)器上，所以purge的時(shí)候，后端app_server找到對(duì)應(yīng)的機(jī)器就可以了。

可以看到在前端中還有一臺(tái)Nginx(purge)的機(jī)器，這臺(tái)機(jī)器是專用于purge的，只要發(fā)送purge指令和需要清除的url到這臺(tái)機(jī)器，就可以找到相應(yīng)的服務(wù)器并清除緩存了。另外，purge時(shí)還需要清理backup機(jī)器上的緩存，所以無論前端機(jī)器增加到多少，purge指令只會(huì)在2臺(tái)機(jī)器上執(zhí)行，如果backup機(jī)器使用到2-3臺(tái)，purge指令就會(huì)在3-4臺(tái)機(jī)器上執(zhí)行，仍然在可接受范圍之內(nèi)。

Nginx squid架構(gòu)作為前端，另有的好處：

1/使用Nginx的日志統(tǒng)計(jì)點(diǎn)擊量非常方便
2/Nginx也可作為緩存，一般可以直接負(fù)責(zé)favicon.ico和logo等固定的小圖片

4、基于Nginx的中層代理

Nginx squid架構(gòu)配合搭建的web服務(wù)器前端系統(tǒng)

在這個(gè)架構(gòu)中，假如后端的app_server上把帖子頁(yè)和列表頁(yè)直接生成了靜態(tài)頁(yè)面，那么使用中層代理再做一次url_hash，將可以解決后端app_server的硬盤容量的壓力，但是如果使用到url_hash的話，那做容錯(cuò)就相對(duì)麻煩了。所以建議不要采用生成靜態(tài)頁(yè)的方式，后端的壓力一般不會(huì)非常的大，所以沒有必要生成靜態(tài)頁(yè)。假如前端squid的命中率實(shí)在太低下，造成大量穿透，可以考慮使用二級(jí)代理暫頂。

5、基于LVS的數(shù)據(jù)庫(kù)雙機(jī)熱備

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

當(dāng)然，數(shù)據(jù)庫(kù)的優(yōu)化還是要細(xì)心做的，參考：

mysql性能的檢查和調(diào)優(yōu)方法

細(xì)心地調(diào)一遍，性能會(huì)好很多。

6、圖片服務(wù)器

圖片服務(wù)器我在這個(gè)架構(gòu)中沒有特別詳細(xì)的介紹，在大型的bbs系統(tǒng)下，圖片常常會(huì)出現(xiàn)容災(zāi)現(xiàn)象——圖片數(shù)量嚴(yán)重超過了單臺(tái)前端服務(wù)器容納能力，導(dǎo)致前端服務(wù)器命中率低下。處理容災(zāi)問題也是非常棘手的，往后會(huì)有更詳細(xì)的介紹。

7、簡(jiǎn)單的點(diǎn)擊量統(tǒng)計(jì)辦法

1/使用js的script標(biāo)簽訪問另一（臺(tái)）組服務(wù)器的空文件，然后定期向數(shù)據(jù)庫(kù)更新

2/在前端的Nginx上直接開啟日志功能，按需要統(tǒng)計(jì)點(diǎn)擊量的鏈接規(guī)則進(jìn)行記錄，然后定期更新數(shù)據(jù)庫(kù)