新型的大型bbs架構（squid+nginx）

這個架構基於squid、nginx和lvs等技術，從架構上對bbs進行全面優化和保護， 有以下特色：

一、高性能：全部的點擊基本上所有由前端緩存負責，提供最快速的處理。

二、高保障度：不需考慮應用程序穩定與否、程序語言是何種、數據庫是何種，都能從架構上保證穩定。

三、高可用性：對應用程序的修改達到最簡化：在程序的某些地方加入清緩存的語句便可，固然還須要作頁面靜態化的工做和統計工做。

這個架構的特色和一些流程的說明：

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

域名分離可使流量分離，緩存策略分離等等，好處諸多。bbs初期必定要作好規劃，將圖片用另外的域名獨立服務，即便沒有足夠機器，域名也要先分 開。另 外，圖片服務器可使用有別於主域名的另外一個域名，一個好處是能夠減小讀取cookie對圖片服務器的壓力，另外一個是提升安全性，避免cookie泄露。

首先看圖，這個圖比較大：

二、使用LVS做爲前端、二級代理和數據庫的訪問入口

使用LVS做爲入口，比其餘任何一種方式都來得更優質。首先LVS的負載能力很強，由於它工做在網絡協議的第4層，使用虛擬ip技術，因此它自己並 不擔負 任何流量的處理，僅僅是一個封包轉發的功能；第二，LVS的配置相對簡單並且穩定，通常去調整的概率比較低，也減小了因人爲等因素而出現故障；第 三，LVS能夠處理任何端口的負載均衡，因此它基本能夠作全部服務的負載均衡和容錯。在這個架構中，除了處理http的80端口以外，LVS也處理了數據 庫mysql的3306端口，在數據庫這個應用中是採用的雙機熱備策略。

三、使用nginx+squid做爲最前端的緩存組合

在這個架構中，是最能體現app_nginx_squid_nginx架構的優點的。在這個架構中的bbs運行在緩存上，用戶每發佈一張帖子，都需 要使用 purge指令清除該帖子的緩存，若是是squid在最前端，那麼每次發佈一張帖子，都須要在全部的squid中調用purge指令，這樣在機器比較多的 時候，purge將成爲一個巨大的壓力。

因此在這裏將nginx放在最前端並使用手工url_hash的方式分流，將常常須要purge的帖子頁面和列表頁面按一個url對應一臺 squid的策 略，分佈到各臺squid上，並提供了一臺或一組backup的squid，個別squid出現異常時將自動使用backup的機器繼續提供一段時間的服 務直到其正常。在這樣的架構下，purge就再也不是關鍵問題，由於一個url只會對應到一臺機器上，因此purge的時候，後端app_server找到 對應的機器就能夠了。

能夠看到在前端中還有一臺nginx(purge)的機器，這臺機器是專用於purge的，只要發送purge指令和須要清除的url到這臺機器， 就能夠 找到相應的服務器並清除緩存了。另外，purge時還須要清理backup機器上的緩存，因此不管前端機器增長到多少，purge指令只會在2臺機器上執 行，若是backup機器使用到2-3臺，purge指令就會在3-4臺機器上執行，仍然在可接受範圍以內。

nginx做爲前端，另有的好處：

1/使用nginx的日誌統計點擊量很是方便
2/nginx也可做爲緩存，通常能夠直接負責favicon.ico和logo等固定的小圖片

四、基於nginx的中層代理

nginx中層代理的優點，在：

nginx和squid配合搭建的web服務器前端系統

這篇文章中有解釋。

在這個架構中，假如後端的app_server上把帖子頁和列表頁直接生成了靜態頁面，那麼使用中層代理再作一次url_hash，將能夠解決後端 app_server的硬盤容量的壓力，可是若是使用到url_hash的話，那作容錯就相對麻煩了。因此建議不要採用生成靜態頁的方式，後端的壓力通常 不會很是的大，因此沒有必要生成靜態頁。假如前端squid的命中率實在過低下，形成大量穿透，能夠考慮使用二級代理暫頂。

五、基於LVS的數據庫雙機熱備

在這個架構中，由於大量的併發和訪問量都由前端的緩存處理掉了，因此後端的mysql主要壓力來自於數據的寫入，因此壓力並非很是大，而且負載比 較穩 定，通常不會隨着訪問量上升而提升過快，估計目前一臺64位的機器，加滿內存並使用高速的硬盤，前端負載數億訪問量時數據庫都不會出現性能問題。在數據庫 這方面應主要考慮故障恢復，由於數據庫崩潰的話，按照通常使用備份恢復的作法，耗時很長並且不免丟失數據，是很棘手的問題。使用雙機熱備的方案，出現故障 時首先可由一臺時刻同步着的備用數據庫即刻充當主數據庫，而後卸下的數據庫能夠有充分的時間對其進行維修，因此是個很安全有效的辦法。

固然，數據庫的優化仍是要細心作的，參考：

mysql性能的檢查和調優方法

細心地調一遍，性能會好不少。

六、圖片服務器

圖片服務器我在這個架構中沒有特別詳細的介紹，在大型的bbs系統下，圖片經常會出現容災現象??圖片數量嚴重超過了單臺前端服務器容納能力，致使 前端服務器命中率低下。處理容災問題也是很是棘手的，日後會有更詳細的介紹。

七、簡單的點擊量統計辦法

1/使用js的script標籤訪問另外一（臺）組服務器的空文件，而後按期向數據庫更新
2/在前端的nginx上直接開啓日誌功能，按須要統計點擊量的連接規則進行記錄，而後按期更新數據庫

FROM:http://sudone.com/archie/archi_bbs.html