分布式集群環境下，如何實現session共享四（部署項目測試）

　　這是分布式集群環境下，如何實現session共享系列的第四篇。在上一篇：分布式集群環境下，如何實現session共享三（環境搭建）中，已經准備好了相關的環境：tomcat、nginx、redis。本篇從不同的角度進行測試，看一看session的使用情況：

　　1.nginx默認負載均衡策略：輪詢

　　2.nginx負載均衡策略：ip_hash

 

1.打包項目

 

2.部署項目到tomcat

 　　2.1.上傳到tomcat_1

 

　　2.2.上傳到tomcat_2

 

 

3.nginx默認負載均衡策略：輪詢

　　3.1.nginx配置

#添加tomcat列表，真實應用服務器都放在這
upstream tomcat_pool{
        #server tomcat地址:端口號 weight表示權值，權值越大，被分配的幾率越大;
        server 192.168.80.22:8080 weight=4 max_fails=2 fail_timeout=30s;
        server 192.168.80.22:8081 weight=4 max_fails=2 fail_timeout=30s;
        
}

 

　　3.2.測試

　　http://192.168.80.22/session-redis-demo/

　　　　3.2.1.谷歌瀏覽器測試

 

 

　　　　3.2.2.火狐瀏覽器測試

 

 

4.nginx負載均衡策略：ip_hash

　　4.1.nginx配置

　　

#添加tomcat列表，真實應用服務器都放在這
upstream tomcat_pool{
        #server tomcat地址:端口號 weight表示權值，權值越大，被分配的幾率越大;
        server 192.168.80.22:8080 weight=4 max_fails=2 fail_timeout=30s;
        server 192.168.80.22:8081 weight=4 max_fails=2 fail_timeout=30s;
        
        #通過ip_hash策略，讓同一客戶端ip地址，去到同一個tomcat后端服務器
        ip_hash;
        
}

 

　　4.2.測試

　　http://192.168.80.22/session-redis-demo/

　　　　4.2.1.谷歌瀏覽器測試

　　　　

 

 

　　　　4.2.2.火狐瀏覽器測試

　　

 

 

5.總結

　　可以看到，同一個web應用，當以nginx+tomcat實現負載均衡集群部署以后，nginx采取不同的負載均衡策略，比如：輪詢、ip_hash。那么session的表現是完全不一樣的。

　　5.1.nginx負載均衡策略：輪詢

　　輪詢方式，客戶端的不同請求在經過nginx負載均衡后，有可能反向代理到tomcat_1，或者反向代理到tomcat_2，由於沒有實現session共享，導致session不可用。

　　5.2.nginx負載均衡策略：ip_hash

　　ip_hast方式，將客戶端的ip地址經過hash處理后，反向代理綁定到后端同一台tomcat服務器（相當於把web應用部署到一台tomcat一樣，同一個客戶的請求綁定到同一台tomcat服務器），因此session可用。該種方式雖然實現了不同客戶端流量的均衡，但對於同一個客戶端來說，存在單點故障，如果后端某一台tomcat服務器出現故障，那么所有之前綁定到該tomcat的客戶端都會收到影響

　　5.3.問題：有沒有可能針對nginx負載均衡策略（輪詢）的基礎上，對session實現共享呢？？？