隨着網站的業務越來越多，網站的服務就變的很重要，假設某天你的服務器掛了，會不會是一個天大的災難呢？而且這種事情發生的概率還不小，斷電了，服務器硬盤壞了，內存壞了等等，都會使你的系統掛掉，而且高並發的訪問有時候也會使系統資源耗盡，然后導致服務器宕機，那么解決方案呢，那就是集群，將相同的系統分別放到不同的web服務器或者硬件服務器，這樣其中一個掛掉了，網站還可以正常運營。
Web應用集群
首先我們應該對web前置做集群，我們的方案是用Haproxy做http協議層的負載均衡，后端部署多個web前置，當然也可以用LVS，負載均衡效率更高，請參考我的另一篇博文：LVS實現負載均衡http://www.cnblogs.com/tangyanbo/p/4305589.html，這篇文章講的是mysql的負載均衡，當然做web應用的集群原理是一樣的，當然還有其他的一些中間件，如Ngnix也是可以的，關於負載均衡的中間件我會另起博客詳細講解的。
各種集群方案的性能問題
理解ip負載均衡和數據鏈路層負載均衡，需要熟悉tcp/ip協議。
反向代理負載均衡
典型的反向代理中間件有Haproxy和Ngnix，請求轉發在http協議層面，其優點是和反向代理服務器功能集成在一起，部署簡單，缺點是需要在中間件做http的轉發，工作在應用層，且請求和響應都要經過反向代理服務器，容易成為性能瓶頸。
系統架構圖：
Ip層負載均衡
通過修改請求目標地址進行負載均衡
具體實現：LVS
優點：ip負載均衡在內核完成ip轉發，較反向代理性能要好，但請求和響應都要經過仍然要經過ip負載均衡服務器，因此吞吐量的瓶頸會出現在ip負載均衡服務器的網卡上。
系統架構圖：
數據鏈路層負載均衡
通過修改mac地址來完成請求的轉發，負載均衡數據分發過程中不修改IP地址，只修改目的mac地址，通過配置真實服務器集群所有機器虛擬IP和負載均衡IP地址一致，從而達到不修改數據包的源地址和目的地址就可以進行數據分發的目的，由於實際處理請求的真實服務器IP和數據請求目的IP一致，不需要通過負載均衡服務器進行地址轉換，可將響應數據包直接返回給用戶瀏覽器，避免負載均衡服務器網卡寬帶成為瓶頸。
系統架構圖：
Session問題
Web應用一般都是需要保持用戶會話的，因此做集群之后會出現問題，默認情況下，客戶端請求是被均勻的分發到后端服務器的，那么同一個會話的兩次請求可能會被分配到不同的服務器，那么session就會丟失。
如何解決這個問題呢？
方案1：session復制
就是將1台服務器的session復制到其它所有的服務器上，這樣無論訪問哪台服務器，都會得到用戶的session
該方案的缺點
當服務器的數量比較大時，session同步將會變得相當耗時
方案2：session粘滯
就是用戶請求一個服務器之后，同一個會話的其它請求，都會被分配到這台服務器，session粘滯的功能由負載均衡中間件完成。
該方案的優點，解決了session復制的性能問題
該方案的缺點，由於用戶的會話被保存到單一的服務器，就容易出現單點故障。
那么有沒有更好的解決方案呢？
方案3：session服務器
部署一個專門的服務，保存用戶session，同時在web服務器本地也保存一份，當本地沒有或者失效時，去訪問session服務器，當然session服務器就成了單點，當用戶量大的時候也容易宕機，這時可以做一個session服務器集群，做主備同步備份，這樣就達到了較好的效果，具體實現可以用redies，memcached等緩存中間件。
系統架構圖：
結語：負載均衡至少有2個優點
1. 多點部署，解決了單點故障問題，提高了網站的可用性
2. 能通過利用更多的硬件資源提高系統性能