Ⅰ 公司准備做個負載均衡伺服器 用linux的lvs 但是突然想到的兩個server 要用相同的資料庫
你要保持數據的一致性，需要一個共享存貯。共享存貯包括網頁，腳本，資料庫等數據。這樣，當用戶連接到不同的伺服器時，可以看到相同的內容。也有利於管理員的維護。其實，沒有共享存貯也可能實現LVS，但是，你要手工進行數據復制同步，管理負擔會很重。
共享存貯，可以通過配置安裝有FREENAS的伺服器來實現，也可購買支持ISCSI等協議的的網路存貯設備來實現。
至於要不要雙網卡，也是看你的性能要求了，理論上，只要通訊正常，單網卡也是可以的。
以下復制章文嵩的LVS原理，請見諒。
一般來說，LVS集群採用三層結構，其體系結構如圖1所示，三層主要組成部分為：
•負載調度器（loadbalancer），它是整個集群對外面的前端機，負責將客戶的請求發送到一組伺服器上執行，而客戶認為服務是來自一個IP地址（我們可稱之為虛擬IP地址）上的。
•伺服器池（serverpool），是一組真正執行客戶請求的伺服器，執行的服務有WEB、MAIL、FTP和DNS等。
•共享存儲（sharedstorage），它為伺服器池提供一個共享的存儲區，這樣很容易使得伺服器池擁有相同的內容，提供相同的服務。
調度器是伺服器集群系統的唯一入口點（SingleEntryPoint），它可以採用IP負載均衡技術、基於內容請求分發技術或者兩者相結合。在IP負載均衡技術中，需要伺服器池擁有相同的內容提供相同的服務。當客戶請求到達時，調度器只根據伺服器負載情況和設定的調度演算法從伺服器池中選出一個伺服器，將該請求轉發到選出的伺服器，並記錄這個調度；當這個請求的其他報文到達，也會被轉發到前面選出的伺服器。在基於內容請求分發技術中，伺服器可以提供不同的服務，當客戶請求到達時，調度器可根據請求的內容選擇伺服器執行請求。因為所有的操作都是在Linux操作系統核心空間中將完成的，它的調度開銷很小，所以它具有很高的吞吐率。
伺服器池的結點數目是可變的。當整個系統收到的負載超過目前所有結點的處理能力時，可以在伺服器池中增加伺服器來滿足不斷增長的請求負載。對大多數網路服務來說，請求間不存在很強的相關性，請求可以在不同的結點上並行執行，所以整個系統的性能基本上可以隨著伺服器池的結點數目增加而線性增長。
共享存儲通常是資料庫、網路文件系統或者分布式文件系統。伺服器結點需要動態更新的數據一般存儲在資料庫系統中，同時資料庫會保證並發訪問時數據的一致性。靜態的數據可以存儲在網路文件系統（如NFS/CIFS）中，但網路文件系統的伸縮能力有限，一般來說，NFS/CIFS伺服器只能支持3~6個繁忙的伺服器結點。對於規模較大的集群系統，可以考慮用分布式文件系統，如AFS[1]、GFS[2.3]、Coda[4]和Intermezzo[5]等。分布式文件系統可為各伺服器提供共享的存儲區，它們訪問分布式文件系統就像訪問本地文件系統一樣，同時分布式文件系統可提供良好的伸縮性和可用性。此外，當不同伺服器上的應用程序同時讀寫訪問分布式文件系統上同一資源時，應用程序的訪問沖突需要消解才能使得資源處於一致狀態。這需要一個分布式鎖管理器（DistributedLockManager），它可能是分布式文件系統內部提供的，也可能是外部的。開發者在寫應用程序時，可以使用分布式鎖管理器來保證應用程序在不同結點上並發訪問的一致性。
負載調度器、伺服器池和共享存儲系統通過高速網路相連接，如100Mbps交換網路、Myrinet和Gigabit網路等。使用高速的網路，主要為避免當系統規模擴大時互聯網路成為整個系統的瓶頸。
GraphicMonitor是為系統管理員提供整個集群系統的監視器，它可以監視系統的狀態。GraphicMonitor是基於瀏覽器的，所以無論管理員在本地還是異地都可以監測系統的狀況。為了安全的原因，瀏覽器要通過HTTPS（SecureHTTP）協議和身份認證後，才能進行系統監測，並進行系統的配置和管理
參考：
http://www..com/s?wd=LVS%E9%9B%86%E7%BE%A4%E7%9A%84%E4%BD%93%E7%B3%BB%E7%BB%93%E6%9E%84+linuxvirtualserver&ie=UTF-8&oe=UTF-8&bar=13&tn=webxunlei_5_cb
Ⅱ 負載均衡伺服器有什麼優缺點
隨著網站、應用訪問量的增加，一台伺服器租用已經不能滿足應用的需求，而需要多台伺服器集群，這時就會用到負載均衡，那麼負載均衡優點有那些呢，壹基比小喻來說說
負載均衡設備優勢
• 負載均衡優化了訪問請求在伺服器組之間的分配，消除了伺服器之間的負載不平衡，從而提高了系統的反應速度與總體性能；
• 負載均衡可以對伺服器的運行狀況進行監控，及時發現運行異常的伺服器，並將訪問請求轉移到其它可以正常工作的伺服器上，從而提高伺服器組的可靠性採用了負均衡器器以後，可以根據業務量的發展情況靈活增加伺服器，系統的擴展能力得到提高，同時簡化了管理。
負載均衡器有多種多樣的形式，除了作為獨立意義上的負載均衡器外，有些負載均衡器集成在交換設備中，置於伺服器與Internet鏈接之間，有些則以兩塊網路適配器將這一功能集成到PC中，一塊連接到Internet上，一塊連接到後端伺服器群的內部網路上。
一般而言，硬體負載均衡在功能、性能上優於軟體方式，不過成本昂貴。當Web伺服器為圖像服務、SSL（安全套接層）會話或資料庫事務而進行優化時，負載均衡器可以體現特別的價值。
當需要進行伺服器升級或系統維護時，保證穩定的伺服器退出服務以避免服務中斷。當選定某台伺服器要退出服務後，將不會將任何新的用戶分配到該伺服器。但是，它可以要該伺服器完成對當前用戶的服務。從而保證了無中斷的優質服務，並且簡化了伺服器群的管理。
智能的伺服器服務恢復
將重新啟動的伺服器應用到服務中時，避免新伺服器因突然出現的流量沖擊導致系統故障是非常重要的。所以，在將新伺服器引入伺服器群時，將逐漸地增加分配到該伺服器的流量，直至達到其完全的處理能力。從而不僅保證用戶在伺服器退出服務時，同時還保證伺服器在啟動期間以及應用程序開始時，均能獲得不間斷服務。
Ⅲ 什麼是資料庫負載均衡
負載均衡集群是由一組相互獨立的計算機系統構成，通過常規網路或專用網路進行連接，由路由器銜接在一起，各節點相互協作、共同負載、均衡壓力，對客戶端來說，整個群集可以視為一台具有超高性能的獨立伺服器。
Ⅳ 如何實現伺服器負載均衡時多台伺服器的數據一樣
部署的時候，這幾台電腦要部署一樣的應用，但是這個負載均衡的支持需要軟體或硬體的支持； 對於資料庫，在這些連到一個資料庫上，是一個機器或一個集群。這樣就能保證數據一樣啦
Ⅳ 雙機熱備和集群和負載均衡的關系
雙機熱備：
只有一個主機在工作，不能夠平均分擔負載，同一時間只有一台機器在工作，如果工作的機器發生故障，則通過集群將所有服務轉移給另外一台機器，轉移時間30秒到2分鍾不等，根據數據量決定。
大多數應用於對安全性要求較高，且無24小時人員值守的環境。
負載均衡：
2台或2台以上的機器同時運行，設備之間沒有主次之分，需要負載均衡設備，需要數據同步軟體，並且基本上只應用前端接收請求的設備。當單台設備出現故障，則由其他設備平均分擔所有應用請求。
大多數應用於訪問量非常大的場合。只要有一台設備在工作，訪問就不會中斷。
雙機熱備與負載均衡區別在於：
1、雙機熱備相當於2台伺服器其中有一台是另一台的備機，也可以互為備機；主機在運行服務時，備機處於檢測狀態，主機發生故障後，備機將接管主機的服務
2、負載均衡是在這2台伺服器（或N多台）之上增加了一台負載均衡伺服器，負載均衡伺服器的作用是把用戶的請求平均分配到每個節點；增加集群整體的處理能力；實現網路訪問的均衡
3、雙機熱備是為保障24*7小時高可用不停機而推出的產品，而負載均衡是解決伺服器壓力過大，網路請求大量並發而設計的產品
4、雙機熱備的優點是：能保障用戶服務不間斷；負載均衡的優點：WEB訪問流暢，用戶請求平均分布在每個節點上
5、雙機熱備缺點：用傳統加加陣列的方式增加了存儲空間，同樣也形成了單點故障；有可能雙機熱備成為虛設，因為一旦陣列崩潰，服務也意味這停止。 （在條件允許的情況下，可以考慮不加陣列，用軟體方式做數據同步，陣列做為備份數據的存儲，不失為一個好辦法）
6、負載均衡的缺點：適用靜態WEB，如果是資料庫將不起作用，資料庫的多向同步目前還沒有完全解決的方案（比如某用戶被分配到1號伺服器，他在資料庫里添加了一條信息；當他下次訪問，卻被分到2號伺服器，那麼他原先的資料庫信息將不存在）
對於動態的、時常更新的WEB，多向的數據同步也很難，不過我現在已經有了不錯的解決辦法 因為增加了負載均衡伺服器，使得各個節點冗餘；但負載均衡器又會形成新的單點故障，所以如果要增加負載均衡設備，一定要選2台做均衡器冗餘。
Ⅵ 如何才能讓兩台sql server 2005伺服器負載均衡
您好，很高興為您解答。
1、企業實現Web伺服器負載均衡
為了將負載均勻的分配給內部的多個伺服器上，就需要應用一定的負載均衡策略。通過伺服器負載均衡設備實現各伺服器群的流量動態負載均衡，並互為冗餘備份。並要求新系統應有一定的擴展性，如數據訪問量繼續增大，可再添加新的伺服器加入負載均衡系統。
對於WEB服務應用，同時有幾台機器提供服務，每台機器的狀態可以設為regular(正常工作)或backup(備份狀態)，或者同時設定為regular狀態。負載均衡設備根據管理員事先設定的負載演算法和當前網路的實際的動態的負載情況決定下一個用戶的請求將被重定向到的伺服器。而這一切對於用戶來說是完全透明的，用戶完成了對WEB服務的請求，並不用關心具體是哪台伺服器完成的。
2、使用網路地址轉換實現多伺服器負載均衡
支持負載均衡的地址轉換網關中可以將一個外部IP地址映射為多個內部IP地址，對每次TCP連接請求動態使用其中一個內部地址，達到負載均衡的目的。很多硬體廠商將這種技術集成在他們的交換機中，作為他們第四層交換的一種功能來實現，一般採用隨機選擇、根據伺服器的連接數量或者響應時間進行選擇的負載均衡策略來分配負載。然而硬體實現的負載控制器靈活性不強，不能支持更優化的負載均衡策略和更復雜的應用協議。
基於網路地址轉換的負載均衡器可以有效的解決伺服器端的CPU和磁碟I/O負載，然而負載均衡器本身的性能受網路I/O的限制，在一定硬體條件下具有一定的帶寬限制，但可以通過改善演算法和提高運行負載均衡程序的硬體性能，來提高這個帶寬限制。不同的服務類型對不同的伺服器資源進行佔用，我們使用的負載衡量策略是使用同一個負載進行評估，這對於大多數條件是適合的，然而最好的辦法是針對不同的資源，如CPU、磁碟I/O或網路I/O等，分別監視伺服器負載，由中心控制器選擇最合適的伺服器分發客戶請求。
3、使用DNS伺服器實現負載均衡
訪問企業網伺服器的用戶急劇增加，一台伺服器難以滿足用戶的訪問需要，那麼如何才能保證用戶的正常訪問呢?解決方法有很多，如使用Windows
2000或Windows Server 2003提供網路負載均衡服務，但該服務的設置非常復雜。而通過DNS伺服器實現網路負載均衡則是一種比較簡單的方法。
企業網通常由很多子網構成，為了降低網路中的數據流量，客戶機最好能訪問處於同一子網內的Web伺服器。雖然實現了網路負載均衡功能，但並不能保證客戶訪問的是本子網的Web伺服器。其實這個問題也很好解決，只要啟用DNS伺服器的「啟用網路掩碼排序」功能即可。在DNS管理器窗口中，右鍵點擊DNS伺服器，在彈出的菜單中選擇「屬性」，然後在屬性對話框中切換到「高級」選項卡，勾選「伺服器選項」列表框中的「啟用網路掩碼排序」選項即可。這樣客戶機每次都能訪問到本子網內的Web伺服器了。完成以上設置後，就使DNS伺服器實現了網路負載均衡功能，把客戶的訪問分擔到每個Web伺服器上，並且還減少了跨子網的網路通信流量，大大降低了企業網的通信負擔。
4、企業實現SQL Server資料庫伺服器負載均衡
MS SQL
Server資料庫伺服器可以說是應用范圍最廣的資料庫產品，並且越來越多地在大型和比較關鍵的應用系統中提供服務。當企業應用越來越復雜、數據量越來越大的時候，SQL
Server資料庫要不停的進行處理、存儲、查詢的工作，這個時候企業就要考慮SQL Server資料庫伺服器的性能和速度及安全性了。然而，長期以來，SQL
SERVER資料庫伺服器都只有「熱備」的解決方案，而沒有「負載均衡」和「集群」的解決方案。
隨著資料庫路由器軟體ICX的出現，為基於MS SQL Server的資料庫系統提供了一種更優秀的集群解決方案。它可以真正的實現SQL
Server資料庫伺服器的動態負載均衡，提高性能和速度;它可以真正的保證SQL
Server資料庫伺服器不間斷的提供服務，在伺服器發生故障的時候實時切換到其他伺服器上繼續提供服務，切換時間為「零」。資料庫路由器是實時並發資料庫事務處理同步復制器和負載平衡器。
所有的資料庫客戶都通過ICX訪問資料庫。當訪問、查詢SQL
Server資料庫的時候ICX可以根據實際情況分配伺服器來提供服務，大大提高服務速度和優化性能，完成負載均衡。ICX可以同時連接多台資料庫，這若乾颱資料庫的內容在任何時刻由ICX保證是完全一致的。也就是說，ICX採用了全新的並發事務處理的方式，向連接的N台資料庫同步復制事務處理，使得系統在任何時刻具有多個一致的最新邏輯資料庫數據集。當其中一台資料庫伺服器發生故障的時候，ICX可以實時的、第一時間切換到其他伺服器上來繼續提供服務。真正的實現零時間的伺服器切換，大大提高安全性，真正意義的實現伺服器不間斷服務。
5：當然自己可以DIY：用f5的網路負載均衡硬體和sql
server的復制技術軟體可以實現負載均衡，故障切換則需要windows的cluster或者sql server
2005的mirror。除了那個f5的硬體外，整個方案成本其實很低。
Ⅶ php手把手教你做網站（二十九）thinkphp6部署多個資料庫
前邊介紹了負載均衡，mysql同步，接下來介紹tp6分布式部署多個資料庫，實現讀寫分離。
tp6的分布式部署讀和寫仍然是一個系統，這里我們分開操作，給用戶展示的就是從資料庫，後端添加文章就是主庫，然後同步到從庫。
1、配置資料庫鏈接參數
目標：實現隨機使用資料庫展示信息，只是讀操作。
測試：前台可以讀取表中內容（存放的不一致），查看是否是隨機顯示的。
打開.env文件進行編輯
說明：
2、編輯database.php
找到deploy設置為1分布式部署，下邊不要改，都是讀，寫入的也就是後端的我們單獨建站連接主庫。
配置完成，tp6使用的是mt_rand取隨機數判斷使用哪個資料庫。
3、資料庫交互寫操作
比如瀏覽量沒必要每次都去更新資料庫，可以先使用redis緩存，存夠1000的整數倍，再去更新資料庫。
4、後台獨立，也就是寫
可以前後端分離，單獨做一個網站（沒有前端）使用ip訪問或者獨立的域名連接後台。
5、上傳附件（jquery ajax跨域上傳）
使用了nginx負載均衡，肯定是多個一樣的網站，如果圖片存放到一個站，別的就不能訪問了，可以單獨設置一個附件（壓縮包，圖片等）伺服器，可以使用二級域名連接，這就要求我們上傳附件的時候，是上傳到附件伺服器。
jqueryURL
API控制器apdpic方法
說明：
也可以先傳到後台伺服器然後使用（php）ftp上傳，或者是通過curl上傳到附件伺服器，感覺那樣畢竟麻煩，直接設置跨域會比較簡單。
也測試了使用jsonp跨域，但是不能上傳附件。
6、thinkphp6實現讀寫分離（在一個站點）
我個人是不喜歡這樣的，負載均衡應該是均衡地讀，也就是前台單獨一個站點，後端的寫是另一個獨立的站點，看個人喜好吧。
獨立後台的優點：可以提升安全性，因為我們的後台網址是不公開的，避免用戶猜測一些後台的信息。
.env配置按照1所述編輯，默認第一個是主庫。
database.php
願大家在新的一年心想事成，萬事如意！！！
Ⅷ 資料庫讀寫分離同步延時問題怎麼解決
業務發展初期，資料庫的壓力相對較小，這時候使用單獨一個庫就可以。
引出的問題：如果資料庫出現故障，我們的業務就不能使用，只能說是停機重啟修復故障。
由於單體帶出的問題，這時候我們就需要加一個備用庫，緊急情況可以用備庫頂上，相當於加一個替補隊員。
通過MySQL自帶的主從同步機制，就可以放我們的替補隊員上線。
當正式隊員（主庫）發生故障，我們就可以人工讓其下線，讓替補隊員（備庫）頂上。
引出的問題：隨著業務大規模爆發，主庫的壓力過大，我們就想讓備庫承擔起更大的責任來。
讀寫分離架構本質也就是主備架構，與主備架構沒有本質區別，就是在主備架構的基礎上，增加一層對讀寫請求的處理，使其能夠更大程度上利用備用庫為我們分擔一些讀的壓力。
讀寫分離架構，需要在中間加一層控制讀寫請求的路由
分庫分表的本質上是切分數據，是由於數據量級的提升，不對數據切分會嚴重影響資料庫讀寫性能。
甚至是如果不切分，磁碟、內存、CPU無法承載這樣的壓力，資料庫隨時在奔潰的邊緣。
分庫分表與前三者是有本質區別的，分庫分表後每一個庫分片都可以採取以上三種方式的任意一種，可以是單體分片，也可以是主備分片，也可以是做了讀寫分離的分片。
分庫分表和前三者中的一種是共生的關系。
不知道如何進行分庫分表設計的可以讀我之前的這篇文章《收好這份武林秘籍，讓你分庫分表再無煩惱》
在應用程序和資料庫之間增加代理層，代理層接收應用程序對資料庫的請求，根據不同請求類型轉發到不同的實例，實現讀寫分離的同時還可以實現負載均衡（讀請求按照負載均衡的規則傳入各個從節點）。
代理也就是藉助中間件的方式，控制不同類型請求，進入不同的資料庫。
目前常用的mysql的讀寫分離中間件有：
在程序中進行控制，我們利用持久層框架的攔截器實現，動態路由不同數據源。
利用Sharding-JDBC也可以實現
實現思路：
主從復制模式，一般都是非同步寫數據到從庫，當然這個非同步也可以設置為同步，只有當從庫寫完成，主庫上的寫請求才能返回。
這種方案是最佳單也是最有效的一種，但也是性能最差的一種，尤其是有大量從庫的情況下，嚴重影響請求效率。
寫請求時緩存記錄一個key，這個key的失效時間設置為主從同步的延時，讀請求的時候先去緩存中確認是否存在key，如果key存在說明發生了寫請求，數據未同步到從庫，這時走主庫即可，若不存在這個key，直接走從庫的查詢即可。
中間件應該也是可以判斷是否同步完成，與使用緩存記錄類似。
這種方案最大的弊端是引入了緩存，系統復雜度上升。
對於一些特殊的業務場景，採用強制讀主庫。
弊端，需要把每一個這種情況都找出來，設置成強制走主庫。
MySQL 在執行完事務後，會將該事務的 GTID 會給客戶端，然後客戶端可以使用該命令去要執行讀操作的從庫中執行，等待該 GTID，等待成功後，再執行讀操作；如果等待超時，則去主庫執行讀操作，或者再換一個從庫執行上述流程。
MariaDB 的 MaxScale 就是使用該方案，MaxScale 是 MariaDB 開發的一個資料庫智能代理服務(也支持 MySQL)，允許根據資料庫 SQL 語句將請求轉向目標一個到多個伺服器，可設定各種復雜程度的轉向規則。
有延遲就有延遲，對數據強一致性要求不高的場景可以放任不管。
Ⅸ nginx負載均衡怎麼訪問資料庫
nginx 是一個輕量級的、高性能的 web server 主要可以干兩件事情：
1、直接作為http server(代替apache，對PHP需要FastCGI處理器支持)；
2、作為反向代理伺服器實現負載均衡
以下我們就來舉例說明如何使用 nginx 實現負載均衡。因為nginx在處理並發方面的優勢，現在這個應用非常常見。當然了Apache的 mod_proxy和mod_cache結合使用也可以實現對多台app server的反向代理和負載均衡，但是在並發處理方面apache還是沒有 nginx擅長。
方法/步驟
1
一、環境：
a. 我們本地是Windows系統，然後使用VirutalBox安裝一個虛擬的Linux系統。
在本地的Windows系統上分別安裝nginx(偵聽8080埠)和apache(偵聽80埠)。在虛擬的Linux系統上安裝apache(偵聽80埠)。
這樣我們相當於擁有了1台nginx在前端作為反向代理伺服器；後面有2台apache作為應用程序伺服器(可以看作是小型的server cluster。;-) )；
b. nginx用來作為反向代理伺服器，放置到兩台apache之前，作為用戶訪問的入口；
nginx僅僅處理靜態頁面，動態的頁面(php請求)統統都交付給後台的兩台apache來處理。
也就是說，可以把我們網站的靜態頁面或者文件放置到nginx的目錄下；動態的頁面和資料庫訪問都保留到後台的apache伺服器上。
c. 如下介紹兩種方法實現server cluster的負載均衡。
我們假設前端nginx(為127.0.0.1:80)僅僅包含一個靜態頁面index.html；
後台的兩個apache伺服器(分別為localhost:80和158.37.70.143:80)，一台根目錄放置phpMyAdmin文件夾和test.php(裡面測試代碼為print 「server1「;)，另一台根目錄僅僅放置一個test.php(裡面測試代碼為 print 「server2「;)。
2
二、針對不同請求 的負載均衡：
a. 在最簡單地構建反向代理的時候 (nginx僅僅處理靜態不處理動態內容，動態內容交給後台的apache server來處理)，我們具體的設置為：在nginx.conf中修改：
復制代碼 代碼如下:
location ~ \.php$ {
proxy_pass 158.37.70.143:80 ;
}
這樣當客戶端訪問localhost:8080/index.html的時候，前端的nginx會自動進行響應；
當用戶訪問localhost:8080/test.php的時候(這個時候nginx目錄下根本就沒有該文件)，但是通過上面的設置 location ~ \.php$(表示正則表達式匹配以.php結尾的文件，詳情參看location是如何定義和匹配的) ，nginx伺服器會自動pass給 158.37.70.143的apache伺服器了。該伺服器下的test.php就會被自動解析，然後將html的結果頁面返回給nginx，然後 nginx進行顯示(如果nginx使用memcached模塊或者squid還可以支持緩存)，輸出結果為列印server2。
如上是最為簡單的使用nginx做為反向代理伺服器的例子；
b. 我們現在對如上例子進行擴展，使其支持如上的兩台伺服器。
我們設置nginx.conf的server模塊部分，將對應部分修改為：
復制代碼 代碼如下:
location ^~ /phpMyAdmin/ {
proxy_pass 127.0.0.1:80 ;
}
location ~ \.php$ {
proxy_pass 158.37.70.143:80 ;
}
上面第一個部分location ^~ /phpMyAdmin/，表示不使用正則表達式匹配(^~)，而是直接匹配，也就是如果客戶端訪問的 URL是以http://localhost:8080/phpMyAdmin/ 開頭的話(本地的nginx目錄下根本沒有phpMyAdmin目錄)，nginx會自動pass到127.0.0.1:80 的Apache伺服器，該伺服器對phpMyAdmin目錄下的頁面進行解析，然後將結果發送給nginx，後者顯示；
如果客戶端訪問URL是http://localhost/test.php 的話，則會被pass到158.37.70.143:80 的apache進行處理。
因此綜上，我們實現了針對不同請求的負載均衡。
如果用戶訪問靜態頁面index.html，最前端的nginx直接進行響應；
如果用戶訪問test.php頁面的話，158.37.70.143:80 的Apache進行響應；
如果用戶訪問目錄phpMyAdmin下的頁面的話，127.0.0.1:80 的Apache進行響應；
3
三、 訪問同一頁面 的負載均衡：
即用戶訪問http://localhost:8080/test.php 這個同一頁面的時候，我們實現兩台伺服器的負載均衡 (實際情況中，這兩個伺服器上的數據要求同步一致，這里我們分別定義了列印server1和server2是為了進行辨認區別)。
a. 現在我們的情況是在windows下nginx是localhost偵聽8080埠；
兩台apache，一台是127.0.0.1:80(包含test.php頁面但是列印server1)，另一台是虛擬機的158.37.70.143:80(包含test.php頁面但是列印server2)。
b. 因此重新配置nginx.conf為：
首先在nginx的配置文件nginx.conf的http模塊中添加，伺服器集群server cluster(我們這里是兩台)的定義：
復制代碼 代碼如下:
upstream myCluster {
server 127.0.0.1:80 ;
server 158.37.70.143:80 ;
}
表示這個server cluster包含2台伺服器
〉然後在server模塊中定義，負載均衡：
復制代碼 代碼如下:
location ~ \.php$ {
proxy_pass http://myCluster ; #這里的名字和上面的cluster的名字相同
proxy_ www.gzlij.comredirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
這樣的話，如果訪問http://localhost:8080/test.php 頁面的話，nginx目錄下根本沒有該文件，但是它會自動將其pass到myCluster定義的服務區機群中，分別由127.0.0.1:80;或者158.37.70.143:80;來做處理。
上面在定義upstream的時候每個server之後沒有定義權重，表示兩者均衡；如果希望某個更多響應的話例如：
復制代碼 代碼如下:
upstream myCluster {
server 127.0.0.1:80 weight=5;
server 158.37.70.143:80 ;
}
4
綜上，我們使用nginx的反向代理伺服器reverse proxy server的功能，將其布置到多台apache server的前端。
nginx僅僅用來處理靜態頁面響應和動態請求的代理pass，後台的apache server作為app server來對前台pass過來的動態頁面進行處理並返回給nginx。
通過以上的架構，我們可以實現nginx和多台apache構成的機群cluster的負載均衡。
兩種均衡：
1)可以在nginx中定義訪問不同的內容，代理到不同的後台server； 如上例子中的訪問phpMyAdmin目錄代理到第一台server上；訪問test.php代理到第二台server上；
2)可以在nginx中定義訪問同一頁面，均衡 (當然如果伺服器性能不同可以定義權重來均衡)地代理到不同的後台server上。 如上的例子訪問test.php頁面，會均衡地代理到server1或者server2上。
實際應用中，server1和server2上分別保留相同的app程序和數據，需要考慮兩者的數據同步。