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