在前面的幾篇文章中，主要談到了在discuz!nt中的跨站快取資料，資料庫負載均衡。但如果要實現將產品分布式布置到若干機器，組成集群來共同支撐起整個業務的話，還是有一定問題的（後面會有所介紹）。下面先介紹一下如何使用 discuz!nt負載均衡方案搭建分布式應用。
下面這張圖簡要說明在我們產品中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 /
server {
listen 8086;
server_name 10.0.2.136;
......
現在，我們可以大體梳理一下整個負載均衡方案，首先是資料庫讀寫分離方式：
然後是分布式快取方案：
當然方案還有一些因素目前沒有過多分析，比較squid檔案加速，比如下面這張經常用在linux平台上的負載均衡架構圖的右側紅框部分：
另外還有cdn等，這些都會在後續章節中進行補充，敬請期待。
blog:
負載均衡方案總結
所有的例子都通過訪問www.ctrip.com為例。這裡只講方案，具體的ngix lvs haproxy怎麼工作的等以後細看了再總結。使用者通過網域名稱解析，得到ip位址114.100.80.100，訪問這台伺服器，這台機器收到請求之後，因為它是知道伺服器集群裡的ip的，然後返回乙個重定向到114....
負載均衡的方案
負載均衡 在計算機集群 網路連線 cpu 磁碟驅動器或其他資源中分配負載，以達到最佳化資源使用 最大化吞吐率 最小化響應時間 同時避免過載的目的。負載均衡既可以採用硬體實現，也可以採用軟體實現。比較知名的f5負載均衡器，就是基於硬體實現的，效能上優於大部分軟體方式，不過成本也比較昂貴。大部分使用者都...
負載均衡方案總結
負載均衡方案總結 所有的例子都通過訪問www.ctrip.com為例。這裡只講方案，具體的ngix lvs haproxy怎麼工作的等以後細看了再總結。http重定向負載均衡 使用者通過網域名稱解析，得到ip位址114.100.80.100，訪問這台伺服器，這台機器收到請求之後，因為它是知道伺服器集...