这是分布式集群环境下,如何实现session共享系列的第四篇。在上一篇:分布式集群环境下,如何实现session共享三(环境搭建)中,已经准备好了相关的环境:tomcat、Nginx、redis。本篇从不同的角度进行测试,看一看session的使用情况:
1.打包项目
2.部署项目到tomcat
2.1.上传到tomcat_1
2.2.上传到tomcat_2
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.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的表现是完全不一样的。
轮询方式,客户端的不同请求在经过Nginx负载均衡后,有可能反向代理到tomcat_1,或者反向代理到tomcat_2,由于没有实现session共享,导致session不可用。
ip_hast方式,将客户端的ip地址经过hash处理后,反向代理绑定到后端同一台tomcat服务器(相当于把web应用部署到一台tomcat一样,同一个客户的请求绑定到同一台tomcat服务器),因此session可用。该种方式虽然实现了不同客户端流量的均衡,但对于同一个客户端来说,存在单点故障,如果后端某一台tomcat服务器出现故障,那么所有之前绑定到该tomcat的客户端都会收到影响
5.3.问题:有没有可能针对Nginx负载均衡策略(轮询)的基础上,对session实现共享呢???
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 [email protected] 举报,一经查实,本站将立刻删除。