分布式Session之坑：分布式Session的使用场景

问题发现

一股脑儿的搞了半个月分布式session，一直**误以为——所谓分布式session不过是多个project共享session这么简单，于是在Maven多模块的项目**的基础上基于：

• Spring Session
• Spring data redis

集成了分布式Session功能。直到模块开发完成，进入测试阶段，我才意识到自己是多麽傻叉，根本没有搞懂技术的使用场景就闷头瞎搞。。。

必要条件

使用分布式Session的必要条件是**反向代理**（理解反向代理？）

• 简单的，反向代理的基础上，单模块（单应用）下的负载均衡。
  
  如果以 Nginx 作为代理服务器， nginx . conf 配置方式如下，单模块下负载均衡。

upstream  module  
{   ip_hash; #ip_hash的方式实现负载均衡server   module.domain1;server   module.domain2;
}server
{listen  80;server_name  www.test.com;location /module{proxy_pass        http://module;}
}

• 复杂的，反向代理的基础上，多模块（多应用）下的负载均衡。
  
  如果以 Nginx 作为代理服务器， nginx . conf 配置方式如下，既包含多模块又包含负载均衡。

upstream  moduleA  
{   ip_hash; #ip_hash的方式实现负载均衡server   moduleA.domain1;server   moduleA.domain2;
}upstream  moduleB   
{   ip_hash; #ip_hash的方式实现负载均衡server   moduleB.domain1;server   moduleB.domain2;
}server
{listen  80;server_name  www.test.com;location /moduleA{proxy_pass        http://moduleA;}location /moduleB{proxy_pass        http://moduleB;}
}

• 特殊的，如果**未使用反向代理，我们可以使用Oauth2.0**,JWT 等**单点登录（SSO）框架，来代替分布式Session**。

原因

《HttpSession之坑：浏览器如何保证从cookie中解析并发送对应的sessionId到目标Url》
我们了解到：

• 浏览器会根据Url的内容，匹配本地cookie集合的 Domain 与 Path 属性；
• 从而得到与Url对应的一些cookie并发送到服务端；
• 服务端再从这些cookie中筛选出**name=seesionid或jsessionid**的cookie。

*所以，*对于分布式Session而言，无论你将 session 存储在任何地方，无论是 redis 、 mysql 还是服务端序列化文件，浏览器解析cookie的方式都不会发生变化—— 相同的url请求才会携带相同的cookie。

又所以，存在于分布式架构的项目，无论是多模块（功能分布）还是单模块集群（流量分布），如果希望共享session**，那么就要保证访问任意项目的url中的**Domain与Path必须相同**。而解决方式就是**反向代理**—— 隐藏了真正的服务端，目标URL总是指向代理服务器。

再所以，如果没有使用反向代理，我们可以选择主动发送sessionid**，代替—— 浏览器解析cookie服务端再筛选。此时我们有更合适的解决方案，那就是Oauth2.0，JWT 等**单点登录（SSO）**框架。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！