我发现了一个商城，我还没有登录，就能够往购物车中增加商品，加了好几件后，我筹备付款，须要我先去登录，登录完之后付款。

当初很多商城，都会要求用户先去登录，登录之后再往购物车中增加商品，这样用户、购物车、商品，三个对象之间就有了绑定关系。

而针对我最开始说的那种状况，其实就是基于session做的，客户端往购物车中增加第一个商品的时候，发送一个申请，服务器收到申请之后，创立session，而后返回以后session对应的一个JessionId，浏览器存储在cookie中，客户端往购物车增加第二个商品时，携带JessionId，服务端收到申请后，更新session。浏览器敞开后，cookie生效，JessionId也就失落了，须要从新往购物车中增加商品，默认状况下，session有效期为30分钟。

在分布式环境下，session就会呈现问题了，如果服务端部署在两个服务器A和B上。第一次往购物车增加商品时，申请落在了服务器A上，服务器A创立了一个session，并返回JessionId，第二次往购物车增加商品时，申请落在了服务器B上，申请携带的JesssionId在服务器B上并不会找到对应的session。这时候服务器B就会创立一个新的session，并返回对应的JessionId，客户端发现第一次增加的商品失落了。。。

接下来，一起来学习分布式环境下session一致性是如何实现的。

一、客户端存储

既然分布式环境中，一个客户端的多个申请可能会落在多个服务器上，那么咱们是否能够扭转策略，间接将session信息存储在客户端？能够的，服务器将session信息间接存储到cookie中，这样就保障了session的一致性，然而并不举荐这样去做，因为将一些信息存储在cookie中，相当于就把这些信息裸露给了客户端，存在重大的安全隐患。

毛病：

  • 安全性存在问题
  • cookie对于数据类型及数据大小有所限度

二、session复制

将服务器A的session，复制到服务器B，同样将服务器B的session也复制到服务器A，这样两台服务器的session就统一了。像tomcat等web容器都反对session复制的性能，在同一个局域网内，一台服务器的session会播送给其余服务器。

毛病：

同一个网段内服务器太多，每个服务器都会去复制session，会造成服务器内存节约。

三、session黏性

利用Nginx服务器的反向代理，将服务器A和服务器B进行代理，而后采纳ip_hash的负载策略，将客户端和服务器进行绑定，也就是说客户端A第一次拜访的是服务器B，那么第二次拜访也必然是服务器B，这样就不存在session不统一的问题了。

毛病：

如果服务器A宕机了，那么客户端A和客户端B的session就会呈现失落。

四、session集中管理

这种形式就是将所有服务器的session进行对立治理，能够应用redis等高性能服务器来集中管理session，而且spring官网提供的spirng-session就是这样解决session的一致性问题。这也是目前企业开发用到的比拟多的一种分布式session解决方案。

五、spring-session实战

Spring提供了解决分布式session的解决方案——Spring Session。Spring Session提供了用于治理用户会话的API和实现。

Spring Session提供了对redis，mongodb，mysql等罕用的存储库的反对，Spring Session提供与HttpSession的通明整合，这意味着开发人员能够应用Spring Session反对的实现切换HttpSession实现。还是原来的配方，产生了不一样的滋味！

Spring Session增加了一个SessionRepositoryFilter的过滤器，用来批改包装申请和响应，包装后的申请为SessionRepositoryRequestWrapper，调用getSession()办法的时候实际上就是调用Spring Session实现了的session。

Spring Session应用非常简单，增加了相干依赖后，间接操作HttpSession就能够实现成果。

第一步：增加Spring Session和 redis的相干依赖

`<dependency>` `<groupId>org.springframework.boot</groupId>` `<artifactId>spring-boot-starter-web</artifactId>``</dependency>``<dependency>` `<groupId>org.springframework.session</groupId>` `<artifactId>spring-session-data-redis</artifactId>``</dependency>``<dependency>` `<groupId>org.springframework.boot</groupId>` `<artifactId>spring-boot-starter-data-redis</artifactId>``</dependency>``<dependency>` `<groupId>org.apache.commons</groupId>` `<artifactId>commons-pool2</artifactId>``</dependency>`

第二步：配置redis相干信息

`spring:` `redis:` `# redis库` `database: 0` `# redis 服务器地址` `host: localhost` `# redis 端口号` `port: 6379` `# redis 明码` `password:` `# session 应用redis存储`  `session:` `store-type: redis`

第三步：我的项目中应用session

`public String sessionTest(HttpServletRequest request){` `HttpSession session = request.getSession();` `session.setAttribute("key","value");` `return session.getAttribute("key").toString();``}`

redis中每个session存储了三条信息。

  • 第一个存储这个Session的id，是一个Set类型的Redis数据结构。这个k中的最初的1439245080000值是一个工夫戳，依据这个Session过期时刻滚动至下一分钟而计算得出。
  • 第二个用来存储Session的详细信息，包含Session的过期工夫距离、最近的拜访工夫、attributes等等。这个k的过期工夫为Session的最大过期工夫 + 5分钟。如果默认的最大过期工夫为30分钟，则这个k的过期工夫为35分钟。
  • 第三个用来示意Session在Redis中的过期，这个k-v不存储任何有用数据，只是示意Session过期而设置。这个k在Redis中的过期工夫即为Session的过期工夫距离。

解决一个session为什么要存储三条数据，而不是一条呢！对于session的实现，须要监听它的创立、过期等事件，redis能够监听某个key的变动，当key发生变化时，能够疾速做出相应的解决。

然而Redis中带有过期的key有两种形式：

  • 当拜访时发现其过期
  • Redis后盾逐渐查找过期键

当拜访时发现其过期，会产生过期事件，然而无奈保障key的过期工夫到达后立刻生成过期事件。

spring-session为了可能及时的产生Session的过期时的过期事件，所以减少了：

spring:session:sessions:expires:726de8fc-c045-481a-986d-f7c4c5851a67`spring:session:expirations:1620393360000`

spring-session中有个定时工作，每个整分钟都会查问相应的spring:session:expirations:整分钟的工夫戳中的过期SessionId，而后再拜访一次这个SessionId，即spring:session:sessions:expires:SessionId，以便可能让Redis及时的产生key过期事件——即Session过期事件。