分布式 WEB应用中Session（会话管理）的变迁之路

一、Session 介绍

---

Session 一词直译为 “会话”，意指有始有终的一系列动作/消息。Session 是 Web 应用蓬勃发展的产物之一。在 Web 应用中隐含有“面向连接”和“状态保持”两个含义，同时也指代了 Web 服务器与客户端之间进行状态保持的解决方案。
​
在 Web 应用诞生之初，应用服务器与浏览器之间仅仅只是基于 HTTP 协议进行通信。而 HTTP 协议是无状态的，也就是说每一个请求之间都是相互独立的，互不关联。但是随着应用业务的复杂，服务器需要按照用户的一系列业务操作向用户提供某些特定的、按需的内容。这时候就需要通过保存用户状态，将用户的请求关联起来。Session 管理正是这一问题的解决方案。

二、单体架构

---

早期的 Web 应用基本都采用的是单体架构，也就是把一个使用了分层架构的 Web 应用部署在单节点 Web 服务器上。虽然采用了分层架构，将整个应用分为了表现层、业务逻辑层和数据访问层，每一层各司其职，让 Web 应用的各个方面都有所改善。但这样的分层只停留于逻辑层面。由于将所有应用都部署在单个服务器节点上，随着应用的不断迭代开发，单体应用将会发展成巨石应用，臃肿不堪，难以维护。
​
在这样的单体架构中，由于所有的用户请求都是由这个唯一的服务器进行响应处理，所以只需要把保存了用户信息和状态的 Session 对象，存放在应用服务器的内存中，就能轻松地达到保持用户状态的目的。

三、集群和分布式架构

---

随着 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，那么转发到的服务器就会不一样。
​

upstream backend{
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
    ip_hash;
}

方案四：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 包：

<!-- redis -->
<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
    <version>1.3.1.RELEASE</version>
    <type>pom</type>
</dependency>

【2】 在 web.xml中，加入关于session的过滤器，只有这样session才会被 Redis所操纵：就实现了 Redis对 session的管理。

<filter>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>