使用 Nginx + Apache + PHP 均衡負載環境

網站隨着改版,用戶的活躍度，以及搜索引擎的優化都帶來了流量激增。

本來單臺服務器平均 CPU 6~10 增高到 30~40 晚上高峯期明顯感到點擊的反應的延遲。

是須要用到集羣的時候了。

在腦中設計該集羣的思路, 使用 Nginx 用於流量分發以及靜態文件處理，多Apache 負責處理PHP程序。

 

這是一種很簡單的均衡負載方式，在Nginx中配置好 upteam，Localhost 與APP0 服務器的文件同步採用NFS，再公用一個單獨的Mysql_server主機。

腦子中的這個設計藍圖，一會兒就能配置出來。但我所要分享的，是一些細微但做用確至關重要的技巧。

首先說一下文件同步，NFS。

程序根目錄下有個 p_w_uploads 目錄，用於寫入存放上傳的附件，除此以外爲了優化反應速度以及減小傳輸量，我把除此之外根目錄下的全部程序文件都複製到 APP0 的本地硬盤上。

好了，一開始就是這麼一架構，開始試驗。

發生的第一個問題是當論壇站長(管理員) 登錄後臺的時候, 因爲均衡負載在不停的 2 個 apache 上跳，因此致使輸入密碼以後怎樣都進不了後臺。(後臺的 cookies 在一關閉瀏覽器以後就會自動清除)

怎麼辦? 你可使用另外一個二級域名域名，指到同一個目錄，但不綁到 Nginx 的 upteam，proxy 的時候直接寫的是 但一臺主機apache 的地址.  例如：proxy_pass http://127.0.0.1:8080;

但還有一個方法是我如今所用的，直接把後臺的php程序過濾出來，綁定在localhost 的Apache上，不參與均衡負載。

        location ~ admincp.php$ {
            proxy_pass   http://127.0.0.1:8080;
            include proxy.conf;
        }

 把以上這配置加插在Nginx php的過濾語法之上， 其實原理跟過濾PHP是同樣的。
凡是 admincp.php  的文件，都proxy 送至 http://127.0.0.1:8080
下邊這段是 Nginx 用於過濾處理 php  的語法。

        location ~ \.php$ {
            proxy_pass   http://server_gznow;
            include proxy.conf;
        }

這麼一來，Nginx 負責出來全部除 php 之外的請求，而php 就交由後方 apache 處理。並配置了 upteam 均衡負載，所以會分配到各個apache 處理達到流量分攤。而  admincp.php 在Nginx 過濾全部php進行均衡負載以前已綁定在單一個apache 上，就是說該程序並沒設置到均衡複製，因此剛纔沒法登錄後臺的問題解決。

好了，這麼作下一個繼續測試，上傳文件，出問題了。

上傳文件爲了標明版權或者防盜鏈，能夠在後臺中設置爲圖片打上水印。

在均衡負載的狀況下，使用批量上傳功能upload的圖片會發生一部分有水印，一部分沒有的狀況。這就確定跟配置了均衡負載的緣由有關。

水印功能須要用到 GD 的JPEG函數，經檢測，2臺用於均衡負載的服務器 GD支持 JPEG 的環境是沒問題的。不使用均衡負載的狀況下全部圖片都能打上水印，這是爲何呢？ 這跟批量上傳構造有關。也不大好說明，但經過如下方法能解決。

從web日誌觀察所得，用戶發帖，會用到 post.php 這個程序文件，而上傳，即會用到 misc.php

因而咱們就跟以前解決後臺登錄的方法同樣，先把 misc.php 綁定在localhost上，經測試。不成功，圖片上傳依舊一部分圖片沒有水印。看來 misc.php 只負責上傳，而打水印的函數應用恐怕就是 post.php 負責的。

因此我就乾脆把 misc.php 跟 post.php 都綁定在單獨的一臺 localhost 上。

這麼有個好處，更加省了 APP0  NFS 同步的流量。原來上傳圖片，用戶都須要兜圈 Nginx --> APP0 --> NFS --> local --> Nginx

如今直接就能  Nginx <--> local

壞處就是，post.php 跟 misc.php 都不能參與均衡複製了，若是用戶發帖上傳得厲害，這就要之後再想別的辦法了....

但就又悟出了一個道理，若是往後Mysql 撐不住了，想進行讀寫分離的時候！能夠用一樣的方法。

例子：先把Mysql 配置爲主從複製

把帖子瀏覽或板塊瀏覽的程序  viewthread.php  forumdisplay.php 等牢牢讀數據的程序 綁在 APP0 ，而後 conf.inc.php 配置文件中 mysql 的地址指定爲mysql 從服務器的地址。

由於帖子瀏覽牢牢須要在 mysql 進行讀的操做，而寫的操做，例如 post.php 以及一些版主管理的頁面都幫到 localhost 而後在conf.inc.php 配置中配置 mysql 主 的服務器地址。這麼讀寫就能分開了！

 

而後還有一個問題，是後臺設置後，Discuz 是有緩存的，每每須要更新緩衝設置才能在前臺中顯示出來。

但因爲設置的admincp.php被綁在單獨一臺服務器上，因此就算更新緩存，也只更新了一臺服務器的緩存。

你能夠有2個方法。

1，修改 Nginx  的配置把 admincp.php 指向到另一臺服務器，更新完以後再換回來。

2，用 Rsync ! 配置好同步的參數，寫成 shell 程序，一執行即刻往主機上同步，這樣就什麼 cache 也跟主機上同樣了。

############################

4.3 更新

############################

通過數天的觀察，發現有個比較奇怪的現象。

Localhost服務器(即Nginx的本地服務器)硬件配置爲Intel奔騰D2.8G 雙核。

裏邊運行的服務也不算多，會佔些資源的應用，Awstats，Cacti，Nginx，Apache，也就這麼幾個。

而APP0 機實際上是個 VMware 的虛擬機安裝的系統，主機的配置是雙路的 Xeon 2.8G 1M 。

先撇開雙路對性能的強化，就Vmware來講，虛擬出來的從系統性能上已是有必定的折扣。

PHP 所測得的CPU整數運算能力以及浮點運算成績都跟真實的機器相差甚遠。

但當我把Nginx upteam 的負載量更多地調配到 APP0 上的時候，雖然Discuz 頁尾顯示的PHP執行的耗時比Localhost多，但的頁面反應速度確高於前者。

如今暫時還在研究成因，但既然是這樣，我就嘗試在Vmware上再模擬多一個應用服務器，APP1。如今+上Localhost就總共有3個Apache 的後端。

 

速度再有明顯的提升！個人見解，是多線程的處理大大有利於Web的應用，這跟多核心CPU有利於WEB服務器性能的道理同樣。由於如今算上Xeon2.8 的HT超線程技術3個Apache後端就總共有 6 個CPU在處理應用。

並且通過實際的測試，發覺NFS的緩存是足夠能減小APP跟Localhost之間的數據傳輸，並且緩存還能提升讀寫性能！比直接在 Vmware 虛擬機的虛擬硬盤上讀寫的速度快得多。二來也方便得多，不用好像以前那樣有更新Discuz 緩存的同步麻煩。因而就直接使用 NFS 把Localhost的web_server 目錄直接 mount 到2個 APP上。