Discuz!NT負載均衡方案

      在前面的幾篇文章中，主要談到了在Discuz!NT中的跨站緩存數據，數據庫負載均衡。但若是要實現將產品分佈式佈置到若干機器，組成集羣來共同支撐起整個業務的話，仍是有必定問題的（後面會有所介紹）。下面先介紹一下如何使用 Discuz!NT負載均衡方案搭建分佈式應用。

     Discuz!NT前端負載均衡能夠是nginx,lvs,haproxy等，固然配置最簡單的基於nginx實現的，下面是它的一些簡介：
    
      Nginx("engine x")是俄羅斯人編寫的十分輕量級的HTTP服務器。它不可是一個高性能的 HTTP 和反向代理服務器，也是一個 IMAP/POP3/SMTP 代理服務器。 Nginx由 Igor Sysoev 爲俄羅斯訪問量第二的 Rambler.ru 站點開發，已經在該站點運行超過兩年半了。Igor 將源代碼以類BSD許可證的形式發佈。
      Google在線安全博客中統計nginx服務或代理了大約全部Internet虛擬主機的4%。而netcraft的統計顯示，nginx服務的主機在過去的一年裏以四倍的速度增加。短短的幾年裏，它的排名已躍進第9。
      Nginx專爲性能優化而開發，性能是其最重要的考量,實現上很是注重效率 。它支持內核Poll模型，能經受高負載的考驗,有報告代表能支持高達 50,000個併發鏈接數。
      Nginx具備很高的穩定性。其它HTTP服務器，當遇到訪問的峯值，或者有人惡意發起慢速鏈接時，也極可能會致使服務器物理內存耗盡頻繁交換，失去響應，只能重啓服務器。例如當前Apache一旦上到200個以上進程， web響應速度就明顯很是緩慢了。而Nginx採起了分階段資源分配技術，使得它的CPU與內存佔用率很是低。Nginx官方表示保持10,000個沒有活動的鏈接，它只佔2.5M內存，因此相似DOS這樣的***對nginx來講基本上是毫無用處的。就穩定性而言, nginx比
lighthttpd更勝一籌。
      Nginx 超越 Apache 的高性能和穩定性，使得國內使用 Nginx 做爲 Web 服務器的網站也愈來愈多，其中包括新浪博客、新浪播客、網易新聞等門戶網站頻道，六間房、56.com等視頻分享網站，水木社區等知名論壇，豆瓣、YUPOO相冊、海內SNS、迅雷在線等新興Web 2.0網站。

      下面這張圖簡要說明在咱們產品中nginx的做用：
     
     
    
     
     
     
      圖中的asp.net就是咱們佈署的相應iis站點應用，相信作過負載均衡的朋友會發現，在大型網站架構中，IIS或其它應用服務器會有許多（節點），而nginx會動態的按照相應權重給不一樣的節點上分配相應請求（有關nginx在window和linux下的配置可參見這篇文章）    

     也就是下面這張圖所說明的：
     
     
     
     
     這裏先拋開對靜態文件緩存（一般使用squid，之後會進行介紹），圖中web服務器（IIS）會有幾個集羣，這就須要將產品分佈佈署到若干機器上，這樣若是某臺機器（節點）上的文件發生變化，就須要有一種同步機制來保證不一樣站點之間的文件一致且是最新的。在discuz!nt產品中，有一些目錄下的文件會頻繁發生變化，好比：

     1.在Discuz!NT的後臺有模板生成機制，它會將前臺的htm模板文件（位於discuz.web\templates目錄下）翻譯並生成爲「aspx」文件，而有關翻譯轉換這部份內容請參見這篇文章。        

     2.前臺discuz.web\config下的配置文件，該目錄下文件存儲的是整個論壇的相應配置信息，全部功能的開關都須要進行記錄，很是重要，當管理員在後臺經過相關頁面修改了這些配置文件後，須要第一時間將這些信息同步到其它分佈節點上。

     這的確是一個挑戰，但好在已有相應的軟件能幫助咱們實現這個基礎功能，就是 cwRsync，它最先是在linux下的一個同步工具，後來有了Windows版本，就是cwRsync，利用它同時再借助windows中的「任務計劃」來建立定時任務，就能夠實現定時同步功能了，之間在windows2003上能夠設置分鐘級別的同步方式，以下：
    
             
  

       而有關如何設置它，能夠參考這篇文章。 

       除了文件同步，還有附件的問題，好比用戶在一個節點上發了主題並上傳了相關附件，那就會形成只有該節點的目錄下有相應附件（如圖片等），而別的節點上沒有。雖然能夠經過上面的同步機制來實現多個節點上同步附近，但這勢必會形成存儲空間和服務器性能上的下降，好在咱們的產品中提供了遠程附件功能，它容許經過FTP方式將上傳到指定節點上的附件上傳到遠程的ftp服務器上，同時修改數據庫中的附件路徑爲FTP上遠程附件的路徑，有關這方面的內容，能夠參見這篇文章。      

  

       除了上面兩個問題，還有nginx對ajax的支持還不夠，由於要在不一樣的節點上均衡負載，因此從一個節點上獲取的腳本可能會被nginx均衡到另一個節點上，從而產生ajax跨節點安全性的問題。這個問題在咱們的產品中很是嚴重。衆所周知，咱們在3.0版本以後將原有的大量的功能所有改爲了ajax方式，好比發帖，回覆，登陸，前臺版主管理操做等等。這個問題要想從根本上解決，只能寄但願於nginx的開發團隊了。但後來通過測試發現，還存在變通的方法，就是在nginx配置文件
（nginx.conf）中，能夠設置下面這些信息：

 

代碼

        location / {
            ......
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;  ;#防止ajax安全請求問題
            proxy_set_header   REMOTE-HOST        $remote_addr; ;#防止ajax安全請求問題
            ...

 

            
        這樣就能夠欺騙IIS，讓它覺得當前被分配的ajax請求就是來自於本地，同時咱們加上相應的端口綁定，可就以實現 ajax請求了，以下：
 

代碼

    ......
    upstream 10.0.2.136 {
       server 10.0.2.136:8086;#端口同樣是爲了防止ajax安全請求問題
       server 10.0.2.137:8086;    
    }

    server {
        listen       8086;
        server_name  10.0.2.136;
    ......

 

        
        注意，必須是同一端口（如上面：8086端口）。這樣就能夠解決ajax安全性調用問題了，若是IP地址怕發生衝突或不夠
用，能夠爲一臺服務器綁定多個IP地址，這樣就能夠解決某些站點必須使用80端口的問題了，詳細設置能夠下載這個文件。

 

        如今，咱們能夠大致梳理一下整個負載均衡方案，首先是數據庫讀寫分離方式：
    
       
    
        而後是分佈式緩存方案：
    
    
         
    
      固然方案還有一些因素目前沒有過多分析，比較squid文件加速，好比下面這張常常用在Linux平臺上的負載均衡架構圖的右側紅框部分：    
    
    
    
       另外還有CDN等，這些都會在後續章節中進行補充，敬請期待。

 

       原文連接:http://www.cnblogs.com/daizhj/archive/2010/06/24/1667422.html

       BLOG: http://daizhj.cnblogs.com/

       做者:daizhj,代震軍