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

來源：http://sudone.com/archie/archi_bbs.html

作者：AYou

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

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

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

3、高可用性：對應用程式的修改達到最簡化：在程式的某些地方加入清緩存的語句即可，當然還需要做頁面靜态化的工作和統計工作。

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

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

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

域名分離可以使流量分離，緩存政策分離等等，好處諸多。bbs初期一定要做好規劃，将圖檔用另外的域名獨立服務，即使沒有足夠機器，域名也要先分開。另外，圖檔伺服器可以使用有别于主域名的另一個域名，一個好處是可以減少讀取cookie對圖檔伺服器的壓力，另一個是提高安全性，避免cookie洩露。

2、使用LVS作為前端、二級代理和資料庫的通路入口

使用LVS作為入口，比其他任何一種方式都來得更優質。首先LVS的負載能力很強，因為它工作在網絡協定的第4層，使用虛拟ip技術，是以它本身并不擔負任何流量的處理，僅僅是一個封包轉發的功能；第二，LVS的配置相對簡單而且穩定，一般去調整的幾率比較低，也減少了因人為等因素而出現故障；第三，LVS可以處理任何端口的負載均衡，是以它基本可以做所有服務的負載均衡和容錯。在這個架構中，除了處理http的80端口之外，LVS也處理了資料庫mysql的3306端口，在資料庫這個應用中是采用的雙機熱備政策。

3、使用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等固定的小圖檔

4、基于nginx的中層代理

nginx中層代理的優勢，在：

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

這篇文章中有解釋。

在這個架構中，假如後端的app_server上把文章頁和清單頁直接生成了靜态頁面，那麼使用中層代理再做一次url_hash，将可以解決後端app_server的硬碟容量的壓力，但是如果使用到url_hash的話，那做容錯就相對麻煩了。是以建議不要采用生成靜态頁的方式，後端的壓力一般不會非常的大，是以沒有必要生成靜态頁。假如前端squid的命中率實在太低下，造成大量穿透，可以考慮使用二級代理暫頂。

5、基于LVS的資料庫雙機熱備

在這個架構中，因為大量的并發和通路量都由前端的緩存處理掉了，是以後端的mysql主要壓力來自于資料的寫入，是以壓力并不是非常大，并且負載比較穩定，一般不會随着通路量上升而提高過快，估計目前一台64位的機器，加滿記憶體并使用高速的硬碟，前端負載數億通路量時資料庫都不會出現性能問題。在資料庫這方面應主要考慮故障恢複，因為資料庫崩潰的話，按照一般使用備份恢複的做法，耗時很長而且難免丢失資料，是很棘手的問題。使用雙機熱備的方案，出現故障時首先可由一台時刻同步着的備用資料庫即刻充當主資料庫，然後卸下的資料庫可以有充分的時間對其進行維修，是以是個很安全有效的辦法。

當然，資料庫的優化還是要細心做的，參考：

mysql性能的檢查和調優方法

細心地調一遍，性能會好很多。

6、圖檔伺服器

圖檔伺服器我在這個架構中沒有特别詳細的介紹，在大型的bbs系統下，圖檔常常會出現容災現象——圖檔數量嚴重超過了單台前端伺服器容納能力，導緻前端伺服器命中率低下。處理容災問題也是非常棘手的，往後會有更詳細的介紹。

7、簡單的點選量統計辦法

1/使用js的script标簽通路另一（台）組伺服器的空檔案，然後定期向資料庫更新

2/在前端的nginx上直接開啟日志功能，按需要統計點選量的連結規則進行記錄，然後定期更新資料庫