137-商城业务-认证服务-分布式session不共享不同步问题与最终解决方案得出

1.cookie与session是个啥?

数据格式:键值对

保存位置:

Session信息是存放在server端,但session id是存放在client cookie的

Cookie是完全保持在客户端的如:IE firefox 当客户端禁止cookie时将不能再使用

生命周期:

两者最大的区别在于生存周期,一个是IE启动到IE关闭.(浏览器页面一关 ,session就消失了),一个是预先设置的生存周期,或永久的保存于本地的文件。(cookie)

举例:比如我登录CSDN,第一次登录时通过用户名登录了,你的用户信息在 服务器端中的session管理器中通过一个session保存起来了,然后在浏览器也保存了一份,

同时设置了过期时间, 你可以试试,重新打开这个浏览器然后直接访问csdn发现直接是登录状态,但是打开别类型的浏览器,发现还需重新登录,说明他是不能跨浏览器的。

详细了解可看这篇

2.浏览器中查看cookie

137-商城业务-认证服务-分布式session不共享不同步问题与最终解决方案得出

可以看到我们cookie中保存的session信息,是有作用域的,不能跨域

3.session共享问题

137-商城业务-认证服务-分布式session不共享不同步问题与最终解决方案得出

137-商城业务-认证服务-分布式session不共享不同步问题与最终解决方案得出

产生问题:上面俩图可以看到体现的session的一些问题,图二可以看到session是有作用域限制的,那么我们从一个服务界面到另一个服务的界面,session的信息会丢失,

同时session是保存在服务器中的,我登录到服务器1的服务中的页面时,页面只会保存在服务器1中

1.session复制,实现简单,但是占大量带宽,影响到业务处理能力

137-商城业务-认证服务-分布式session不共享不同步问题与最终解决方案得出

2.客户端存储  节省了服务器资源,但是cookie容量限制,并且cookie不安全

137-商城业务-认证服务-分布式session不共享不同步问题与最终解决方案得出

3,客户端服务端一对一  ——hash一致性  这样操作简单,只需修改nginx负载均衡的配置,但是随着业务的扩展,服务器增加后,需要重新hash,这点比较麻烦,并且session只保存

在一台服务器丢失了 需要重新登录

137-商城业务-认证服务-分布式session不共享不同步问题与最终解决方案得出

4.redis统一存储 好的,看到下面的rediss 不用说了吧,妥了老铁!唯一麻烦的点就只是多了一次网络调用,这点通过后面说的springsession可以完美解决

137-商城业务-认证服务-分布式session不共享不同步问题与最终解决方案得出

 

上一篇:(leetcode)137. 只出现一次的数字 II-2021/4/30


下一篇:Java算法测验第二次