简单的Session共享

   httpGet.setHeader("Content-Type", "application/json;charset=utf-8");

cookie 

Cookie实际上考虑的是为了记录用户在一段时间内访问web应用服务的行为路径

弊端:Cookie大小和个数有限制 Cookie安全型比较低,容易被攻击

Session

Session是另一种记录客户状态的机制,客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录在服务器上。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了

不同的是Cookie保存在客户端浏览器中,而Session保存在服务器上。

session的三种工作方式。   

 1.基于URL Path Parameter,默认支持    

 2.基于Cookie,默认没有修改Context容器的Cookies标识,默认也是支持的。( 如果客户端支持cookies,tomcat也会解析Cookie中的JSESSIONID,并覆盖URL中JSESSIONID)

1)new Request

2)解析path,parameters 拿到Session ID 设置到Request对象中

3)如果支持Cookie,从Cookie中拿到Session ID并覆盖之前的

4)getSession  

5)findSession 根据Session ID在session集合中查找已经存在的Session对象

6) new 不存在将创建一个新的对象

7)add to sessions 集合中

8)返回Standard Session对象  根据这个Session ID新增一个Cookie,并将这个Cookie设置到Http协议头中

9)session.getSession 返回StandardSessionFacade对象

10)Servlet中可以在HttpSession对象中操作,包括修改删除等,Session的生命周期由Manager来空值,客户端无需关注

HttpServletRequest定义了获取session的方法,该方法有两种重载形式:  

   request.getSession(Boolean  boo);  

               request.getSession(true):若存在会话则返回该会话,否则新建一个会话。    

                 request.getSession(false):若存在会话则返回该会话,否则返回NULL   

                  request.getSession()默认为true方式

 Session声明周期     

 创建:第一次执行request.getSession()时创建    

  销毁: 1)服务器(非正常)关闭时 2)session过期/失效(默认30分钟,从不操作服务器端的资源开始计时) 3)手动销毁session:session.invalidate()

问题:单服务器web应用中,session信息只需存在该服务器中。但随着分布式系统的流行,单系统已经不能满足用户的需求,集群方式部署服务器已在很多公司运用起来,当高并发量的请求到达服务端的时候通过负载均衡的方式分发到集群中的某个服务器,这样就有可能导致同一个用户的多次请求被分发到集群的不同服务器上,就会出现取不到session数据的情况,于是session的共享就成了一个问题。

假设用户包含登录信息的session都记录在第一台web-server上,反向代理如果将请求路由到另一台web-server上,可能就找不到相关信息,而导致用户需要重新登录。

1.session复制(同步)多个web-server之间相互同步session,这样每个web-server之间都包含全部的session 优点:web-server支持的功能,应用程序不需要修改代码 缺点: session的同步需要数据传输,占内网带宽,有时延 所有web-server都包含所有session数据,数据量受内存限制,无法水平扩展,有更多web-server时要歇菜

2.客户端存储法 服务端存储所有用户的session,内存占用较大,可以将session存储到浏览器cookie中,每个端只要存储一个用户的数据了 优点:服务端不需要存储 缺点: 每次http请求都携带session,占外网带宽; 数据存储在端上,并在网络传输,存在泄漏、篡改、窃取等安全隐患 session存储的数据大小受cookie限制,“端存储”的方案虽然不常用,但确实是一种思路。

3.反向代理hash一致性        让同一个用户的请求落在一台web-server上(ip-hash) 优点: 只需要改nginx配置,不需要修改应用代码 负载均衡,只要hash属性是均匀的,多台web-server的负载是均衡的 可以支持web-server水平扩展(session同步法是不行的,受内存限制) 不足: 如果web-server重启,一部分session会丢失,产生业务影响,例如部分用户重新登录 如果web-server水平扩展,rehash后session重新分布,也会有一部分用户路由不到正确的session

4.后端统一集中存储        存储到数据库或者存储到缓存 优点: 没有安全隐患 可以水平扩展,数据库/缓存水平切分即可 web-server重启或者扩容都不会有session丢失 不足: 增加了一次网络调用,并且需要修改应用代码

猜你喜欢

转载自blog.csdn.net/qq_21325705/article/details/84554797