本文介绍了Cookie和Session的区别，包括它们的数据格式、保存位置、生命周期。着重阐述了Session在不同浏览器间无法共享的问题，以及在服务器集群环境下面临的挑战。针对这些问题，提出了几种解决方案，如Session复制、客户端存储、一致性Hash和Redis统一存储。最终，推荐了通过扩大Cookie作用域和使用Redis来解决集群中的Session共享问题。
1.cookie与session是个啥？
数据格式：键值对
保存位置：
Session信息是存放在server端，但session id是存放在client cookie的
Cookie是完全保持在客户端的如：IE firefox 当客户端禁止cookie时将不能再使用
生命周期:
两者最大的区别在于生存周期，一个是IE启动到IE关闭.(浏览器页面一关 ,session就消失了)，一个是预先设置的生存周期，或永久的保存于本地的文件。(cookie)
举例：比如我登录优快云，第一次登录时通过用户名登录了，你的用户信息在 服务器端中的session管理器中通过一个session保存起来了，然后在浏览器也保存了一份，
同时设置了过期时间, 你可以试试，重新打开这个浏览器然后直接访问csdn发现直接是登录状态，但是打开别类型的浏览器，发现还需重新登录，说明他是不能跨浏览器的。
2.浏览器中查看cookie
可以看到我们cookie中保存的session信息，是有作用域的，不能跨域
3.session共享问题
产生问题：上面俩图可以看到体现的session的一些问题，图二可以看到session是有作用域限制的，那么我们从一个服务界面到另一个服务的界面，session的信息会丢失，
同时session是保存在服务器中的，我登录到服务器1的服务中的页面时，页面只会保存在服务器1中
4.解决方案分析与最终方案得出
1.session复制,实现简单，但是占大量带宽，影响到业务处理能力
2.客户端存储 节省了服务器资源，但是cookie容量限制，并且cookie不安全
3,客户端服务端一对一 ——hash一致性 这样操作简单，只需修改nginx负载均衡的配置，但是随着业务的扩展，服务器增加后，需要重新hash，这点比较麻烦，并且session只保存
在一台服务器丢失了 需要重新登录
4.redis统一存储 好的，看到下面的rediss 不用说了吧，妥了老铁！唯一麻烦的点就只是多了一次网络调用，这点通过后面说的springsession可以完美解决
5.最终解决方案
关于集群中的session问题有了解决方案，那么域名问题呢？
这里我们当保存好信息到session后，往浏览器中在cookie中保存session信息 时 选择扩大其作用域，比如原本的 auth.gulimall.com 变为 gulimall,com
所以最终的解决方案概览如下图
扫一扫
8679
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
