1.需求
在傳統的Web小規模并發的情況下，單個Tomcat容器往往就能勝任請求的負載與處理，如圖1所示的方案一。方案一的好處在于，部署簡單，維護友善，在Web服務發生變更之後，能夠快速更新；除此之外，在使用者Session管理方面也十分簡單：将所有Session存儲至本地伺服器即可。但是該方案存在并發規模小、單點故障等原因。
針對方案一存在的負載小、單點故障等因素，方案二進行了大規模的改進。首先，使用NGINX+keepalived取代原來的單節點Tomcat，同時以NGINX作為反向代理伺服器，管理多個Tomcat服務節點。如圖2所示。
從圖2可以看出，單節點部署的使用者請求負載，從單個Tomcat伺服器轉移到了Nginx負載（還有其他負載均衡方式）下的多個Tomcat節點，進而實作了單個Web服務的負載均衡與備份。而各個Tomcat節點與NGINX之間，則是采用反向代理的形式進行通信，具體方法有以下五種：
**1、輪詢（預設）
每個請求按時間順序逐一配置設定到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。
upstream backserver {
server 192.168.0.14;
server 192.168.0.15;
} **
**2、指定權重
指定輪詢幾率，weight和通路比率成正比，用于後端伺服器性能不均的情況。
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
**3、IP綁定 ip_hash
每個請求按通路ip的hash結果配置設定，這樣每個訪客固定通路一個後端伺服器，可以解決session的問題。
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
**
**4、fair（第三方）
按後端伺服器的響應時間來配置設定請求，響應時間短的優先配置設定。
server server1;
server server2;
fair;
**5、url_hash（第三方）
按通路url的hash結果來配置設定請求，使每個url定向到同一個後端伺服器，後端伺服器為緩存時比較有效。
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
具體NGINX+Keepalived+Tomcat的負載均衡搭建請參考我的另一篇部落格。
2.帶來的問題