标签：分析 存储 浏览器 控制技术 会话 Session Cookie 服务器

**

一、会话控制

**
浏览器访问服务器时会自动携带Cookie，相同域名登录验证根据浏览器端存储的名为JSESSIONID的Cookie查找服务器端保存的Session对象。但这样会出现较多问题：

1、在分布式和集群环境下，每个具体模块运行在单独的Tomcat上，而Session是被不同Tomcat所“区隔”的，所以不能互通，会导致程序运行时，用户会话数据发生错误。有的服务器上有，有的服务器上没有。

针对这个问题的解决办法有如下：
（1）、Session同步
Session同步可以解决不同服务器之间的session问题，但是也造成Session在各个服务器上“同量”保存。TomcatA保存了1G的Session数据，TomcatB也需要保存1G的Session数据。数据量太大的会导致Tomcat性能下降

（2）将Session数据存储在Cookie中
即所有会话数据在浏览器端使用Cookie保存，服务器端不存储任何会话数据。但这个方法缺陷更加明显：
Cookie存储的数据量有限，一般只能存储4KB大小的文件，同一个域名只能保存20个cookie，
Cookie数据在浏览器端存储，很大程度上不受服务器端控制，如果浏览器端清理Cookie，相关数据会丢失。
（3）反向代理hash一致性
具体一个浏览器，专门访问某一个具体服务器，如果服务器宕机，会丢失数据。存在单点故障风险。仅仅适用于集群范围内，超出集群范围，负载均衡服务器无效
（4）后端统一存储Session数据
使用Redis数据库统一储存session。Session数据存取比较频繁。使用Redis内存访问速度快，Session有过期时间，Redis这样的内存数据库能够比较方便实现过期释放。Redis可以配置主从复制集群，不担心单点故障

标签：分析,存储,浏览器,控制技术,会话,Session,Cookie,服务器
来源： https://blog.csdn.net/TMHJHZTMGB/article/details/110948551

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。