一、Session 介绍
Session 一词直译为 “会话”,意指有始有终的一系列动作/消息。Session 是 Web 应用蓬勃发展的产物之一。在 Web 应用中隐含有“面向连接”和“状态保持”两个含义,同时也指代了 Web 服务器与客户端之间进行状态保持的解决方案。
二、单体架构
早期的 Web 应用基本都采用的是单体架构,也就是把一个使用了分层架构的 Web 应用部署在单节点 Web 服务器上。虽然采用了分层架构,将整个应用分为了表现层、业务逻辑层和数据访问层,每一层各司其职,让 Web 应用的各个方面都有所改善。但这样的分层只停留于逻辑层面。由于将所有应用都部署在单个服务器节点上,随着应用的不断迭代开发,单体应用将会发展成巨石应用,臃肿不堪,难以维护。
三、集群和分布式架构
随着 Web 应用的发展,用户访问量和业务复杂度与日俱进,应用的性能和代码的维护难度成为应用的瓶颈,为了突破瓶颈,开发者开始尝试在应用架构中引入负载均衡器,继而演化出了集群和分布式两种架构类型。
集群:是指在多个服务器节点上部署相同的应用,例如上图中的服务器B和服务器C,然后通过负载均衡的分发功能,把用户请求分发到集群中的任意一个服务节点上。如果有更大的访问量,只要向集群中增加服务器节点,就能改善压力。集群既能保证应用的高可用,又能提高应用的负载能力。
分布式:是把原来的单体架构应用,通过分而治之的手段,按照业务功能,切分成一些小的模块应用,部署在不同服务器节点上,例如上图中的服务器A和服务器B。然后通过负载均衡和门户应用整合起来,组成一个完成的应用。
集群和分布式架构中,后端包含了多个服务器节点。当用户进行登录时,登录请求是由其中一个服务器节点进行响应,而后续的用户请求将可能被负载均衡器分发到其他服务器节点,这时候就可能因为这个服务节点上没有用户 Session ,导致服务器判定用户是未登陆状态,让用户重新登录。所以,在集群和分布式架构中,必须保证用户进行登录后,架构中的所有服务器节点都能共享 Session 数据,常用的 Session 管理方案有如下3种:
方案一:将 Session 对象保存在 Cookie,然后存放在浏览器端
每次浏览器向服务器发送请求的时候,都会把整个 Session 对象放在请求里一起发送到服务器,以此来实现 Session 共享。这种方法实现起来特别方便,但是由于 Cookie 的存储容量较小,且不安全。所以这个方案只适用于 Session 数量小和安全性不高的场景。
方案二:Session 复制
部分应用服务器能够支持 Session 复制功能,例如 Tomcat。用户可以通过修改配置文件,让应用服务器进行 Session 复制,保持每一服务节点的 Session 数据达成一致。但是这个方案的实现依赖于应用服务器。当应用被大量用户访问时,每个服务器都需要有一部分内存用来存放 Session,同时因为大量 Session 通过网络传输进行复制,将会占用网络资源,这可能因为网络延迟导致程序异常。
方案三:Session 粘滞
利用负载均衡的分发能力,将同一浏览器上同一用户的请求,都定向发送都固定的服务器上,让这个服务器处理该用户的所有请求,这样只要这个服务器上保存的用户 Session,就能保证用户的状态一致性。但是这个方案依赖于负载均衡器,而且只适用于横向扩展的集群场景,不能满足分布式场景。同时,当指定的服务器宕机后,会session 信息丢失的情况。也无法利用 Nginx负载均衡,提高服务器的利用率,而且如果 Nginx不是放在最前面一层,那么拿到的就可能不是用户的真实ip,那么转发到的服务器就会不一样。
方案四:Session 集中管理方案选择
这里简单介绍下 Spring Session。Spring Session 是 Spring 提供的一套 Session 管理方案,通过一个 SessionFilter 将所有访问应用的请求都拦截下来,然后使用 Request 包装类接管 Session 管理。将 Session 从Web 容器中拦截下来后,Session 会被存储在独立的存储服务器中。目前支持多种形式的 Session 存储器:Redis、Database、MogonDB等。当 Request 进入 Web 容器,根据 Request 获取 Session 时,由 Spring Session 负责从存储器中获取 Session,如果存在则返回,如果不存在则创建并持久化至存储器中。Spring Session不与应用服务器耦合,能使用于常规服务器。同时还提供了浏览器下对同一应用存储多个 Session 等功能。
【1】引入Spring-Session 相关 jar 包: