这是分布式集群环境下，如何实现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实现共享呢？？？