详解Spring Session

1.背景

1.1 session

说起session还要从http协议说起，http协议是无状态协议。所谓无状态协议，就是http请求之间是相互独立的。比如，你用百度搜索“2020年NBA总冠军是谁”，百度服务器会给你一个响应，这一次的http请求就算完事儿了。当你再去搜索“谁会赢得2020年美国总统大选”，这个时候百度服务器并不会感知到你上一次搜索了啥，你的两次搜索是完全独立的。可以用下面的图简略表示下。

对于百度搜索这样的场景，这样的无状态协议问题不大。但是对于大多数场景，这种无状态协议是远远不够的。比如，你要查看自己淘宝的购物车，淘宝会返回一个登陆页面，这个时候你输入了自己的用户名和密码，发起了一次登陆的http请求，假设用户名和密码都正确，这个时候系统会自动跳转到登陆成功的页面；但是当你点击付款的时候，发起了一次付款的http请求，这个时候系统会校验当前的用户信息，以及用户是否登陆，由于http是无状态协议，服务器并不知道你已经通过上次请求了登陆，会再次返回登陆页面。这样每操作一次都需要登陆一次，用户体验极差。

为了解决类似的问题，session应运而生。以淘宝登陆为例，它的主要工作流程如下：

1. 用户在登陆页面输入用户名和密码，点击登陆，发送登录请求至淘宝服务器。

2. 服务器接收到请求后，校验请求头部中未携带sessionId,于是创建session对象，并将sessionId放入response的cookie对象中。

3. 服务器校验用户和密码成功后，将用户信息存放至session中。请求返回，浏览器将response中cookie缓存至本地。

4. 用户点击付款，发送付款请求，由于请求的是相同的域名，浏览器会自动在请求头部中添加sessionId。

5. 服务器接收到请求后，识别到请求头部中sessionId，直接根据sessionId去查找上一次创建的session对象，并将该对象放入request对象中。

6. 服务器从request的session对象中获取到用户信息，校验通过，付款成功。

      

        

1.2 分布式应用存在的问题

1.2.1问题复现

session的出现很大程度上解决了http请求无状态的问题。但是，随着业务量增加和对服务高可用的诉求，分布式应用和微服务得到了越来越广泛的应用，这样使用传统的session就会存在问题。接下来我们就来复现一下这个问题。

1.使用springboot实现一个简单的登陆功能

访问http://localhost:8080/login，如果用户已经登陆，则直接返回主页面；如果用户未登陆，跳转至登陆页面。在登陆页面输入用户名和密码，点击登陆，跳转至登陆成功页面（此处不对用户名和密码进行校验）。

package com.example.mysession.collector;

import org.springframework.stereotype.Controller;
import org.springframework.util.StringUtils;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.context.request.RequestContextHolder;
import org.springframework.web.context.request.ServletRequestAttributes;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

@Controller
public class LoginContoller {

    /**
     * 返回登陆页面
     */
    @GetMapping("/login")
    public String login() {
        HttpServletRequest request = getRequest();
        HttpSession session = request.getSession();
        // session中包含用户信息，直接返回主页
        String usernameInSession = (String) session.getAttribute("username");
        if (!StringUtils.isEmpty(usernameInSession)) {
            return "main";
        }

        // 重定向至登陆页面
        return "loginpage";
    }


    /**
     * 处理登陆请求
     */
    @PostMapping("/doLogin")
    public String doLogin(@RequestParam String username, @RequestParam String password) {
        HttpServletRequest request = getRequest();
        HttpSession session = request.getSession();
        // 将用户名放入session，并通知用户登陆成功（这里不对用户名和密码进行校验）
        session.setAttribute("username", username);
        return "main";
    }


    private HttpServletRequest getRequest() {
        ServletRequestAttributes servletRequestAttributes =
            (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
        return servletRequestAttributes.getRequest();
    }
}

2.我们来分析一下这个简单的登陆流程

（1）springboot启动后，访问http://localhost:8084/login。回想1.1中的流程，由于我们是首次访问，请求头中没有带sessionId，因此tomcat会为我们创建一个session对象，并将sessionId返回，浏览器将sessionId缓存至本地。

请求前：

请求后：

（2）输入用户名和密码，点击登陆。这时请求会带上SessionId，tomcat会根据SessionId找到之前创建session，并将其放入request对象中。doLogin()方法在处理时会将用户信息存入session。

（3）再访问http://localhost:8084/login。此次请求浏览器依然会将SessionId放入请求头部，login()方法根据SessionId找到session，进而在该session中找到用户信息，判断当前用户已经登陆，直接返回登陆成功页面。

3.使用nginx反向代理，实现简单的集群

（1）上述是单机环境，session完美解决了http协议无状态的问题，使得我们不需要频繁登陆。接下来，我们启动两个相同的服务（1中简单登陆服务），他们分别监听8084和8085端口。

（2）测试两个服务是否都正常可用

8084：

8085：

（3）使用ngnix进行反向代理

nginx.conf：

#user  nobody;
worker_processes  1;

events {
    # 并发连接数量
    worker_connections  1024;
}


http {
    # tomcat集群
    upstream tomcat_servers{
        server 127.0.0.1:8084;
        server 127.0.0.1:8085;
    }

    server {
        # 监听80端口
        listen       80;
        server_name  localhost;

        # 将请求交给tomcat集群处理
        location / {
		    proxy_set_header Host $host:$server_port;
            proxy_pass http://tomcat_servers;
        }

    }
}

4.出现问题

（1）访问http://localhost/login。

（2）输入用户名和密码，点击登陆。

(3) 再次访问http://localhost/login。按照之前单节点的处理逻辑，应该返回登陆成功的页面才对，但是现在好像有点不太对？

1.2.2 原因分析

上述的现象比较明显，就是服务器好像并没有记住我们已经登陆过了。要解释这个问题我们首先要看下session的本质，session本质是tomcat为我们创建的一个对象，它使用ConcurrentHashMap保存属性值。tomcat本质也是一个Java程序，一个tomcat容器（8084）创建的session另外一个tomcat（8085）自然是获取不到的。

好了，有了上面的知识，我们再来看看这个问题是怎么产生的。我们启动了两个tomcat服务器（分别监听8084和8085端口），使用ngnix进行反向代理，为了达到负载均衡的效果，我们在ngnix上置的策略是轮流访问8084和8085，也就是请求第一次访问8084节点，第二次访问8085节点，再是8084...以此类推。

当我们第一次访问http://localhost/login时，ngnix会为我们路由到8084节点，由于是第一次访问8084会为我们创建一个session，sessionId为32AC7EEFE4CD0486F88B23B84594A768，并返回至浏览器。

当我们输入用户名和密码，点击登陆，第二次访问时，ngnix会为我们路由到8085节点。这一次我们请求头部带了SessionId:32AC7EEFE4CD0486F88B23B84594A768，但是这个session是8084节点创建的，8085节点获取不到这个session，所以8085又会创建一个新的session，709F94B639FFD8DF34110E1F1760D84D，返回至浏览器。

至此我们已经登陆成功了。我们再次访问http://localhost/login，ngnix会为我们路由到8084节点，请求头部带上上一次请求返回的sessionId:709F94B639FFD8DF34110E1F1760D84D，而这个是8085节点创建的，8084节点获取不到这个session，所以认为我们没有登陆过。

...

如此循环，我们会发现每一次请求，tomcat都会为我们创建一个session对象，而一个tomcat容器创建的session对象，另一个tomcat容器获取不到，这就是问题的根源。可能有的人会说，这不简单，在ngnix上配置策略，让每次来自同一个IP的用户访问同一个tomcat容器，这样不就好了？但是这样主要有两个问题，第一，如果一个节点出问题挂掉了，那么之前一直访问这个节点的用户登陆信息就丢失了，需要重新登陆，这显然不合理；第二，移动端应用越来越多，而移动端可能换一个基站IP就变了。

2.spring session

2.1 解决问题的原理

知道了上述问题的原因，我们来看看怎么解决这个问题。首先来回顾下tomcat处理请求的流程

从上面的分析以及工作流程我们可以知道，解决该问题的关键就是如何让多个tomcat共享同一个session。我们自然而然就会想到，把session存储在一个公共的地方，这样每个tomcat就都会获取到了，这个公共的地方就是数据库（本文以Redis为例）。spring session的实现原理，就是在tomcat中加入了一个优先级很高的filter，来一个偷天换日，将request中的session置换为spring session，而这个spring session就存储在数据库中（Redis）,这样一来，不同的tomca就可以共享同一个session啦。具体的细节我们在源码解析中再详细介绍，先看看spring session如何使用。

2.2 spring session的使用

可以参考spring官网https://docs.spring.io/spring-session/docs/1.3.0.RELEASE/reference/html5/guides/httpsession.html

1.添加依赖

    4.0.0
    
        org.springframework.boot
        spring-boot-starter-parent
        2.3.5.RELEASE
         
    
    com.example
    my-session
    0.0.1-SNAPSHOT
    my-session
    Demo project for Spring Boot

    
        1.8
    

    
        
            org.springframework.boot
            spring-boot-starter-web
        

        
            org.springframework.boot
            spring-boot-starter-thymeleaf
        

        
        
            org.springframework.session
            spring-session-data-redis
        
        
            org.springframework.boot
            spring-boot-starter-data-redis
        
    

    
        
            
                org.springframework.boot
                spring-boot-maven-plugin
            
        
    

 

2.添加一个配置文件

package com.example.mysession.config;

import org.springframework.context.annotation.Bean;
import org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory;
import org.springframework.session.data.redis.config.annotation.web.http.EnableRedisHttpSession;

@EnableRedisHttpSession
public class SpringSessionConfig {

    @Bean
    public LettuceConnectionFactory connectionFactory() {
        return new LettuceConnectionFactory();
    }
    
}

3.向spring中注入一个Initializer

package com.example.mysession.initializer;

import jdk.nashorn.internal.runtime.regexp.joni.Config;
import org.springframework.session.web.context.AbstractHttpSessionApplicationInitializer;
import org.springframework.stereotype.Component;

@Component
public class Initializer extends AbstractHttpSessionApplicationInitializer {

    public Initializer() {
        super(Config.class);
    }
}

4.测试

（1）访问http://localhost/login。

（2）输入用户名和密码，点击登陆。

（3）再次请求http://localhost/login。直接跳转至登陆成功页面。

这里我们可以看到，第二次请求和第三次请求携带的都是第一次请求返回的sessionId。

2.3 spring session源码解析

spring的官网写的非常清晰，我们使用@EnableRedisHttpSession注解创建了一个springSessionRepositoryFilter。而这个filter就是用来将tomcat创建的session对象替换为spring session。

实际处理的Filter时SessionRepositoryFilter，而SessionRepositoryFilter又继承OncePerRequestFilter，所以dofilter()方法在OncePerRequestFilter类中实现。

OncePerRequestFilter中的dofilter()方法

	/**
	 * This {@code doFilter} implementation stores a request attribute for "already
	 * filtered", proceeding without filtering again if the attribute is already there.
	 * @param request the request
	 * @param response the response
	 * @param filterChain the filter chain
	 * @throws ServletException if request is not HTTP request
	 * @throws IOException in case of I/O operation exception
	 */
	@Override
	public final void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain)
			throws ServletException, IOException {

		if (!(request instanceof HttpServletRequest) || !(response instanceof HttpServletResponse)) {
			throw new ServletException("OncePerRequestFilter just supports HTTP requests");
		}
		HttpServletRequest httpRequest = (HttpServletRequest) request;
		HttpServletResponse httpResponse = (HttpServletResponse) response;
		String alreadyFilteredAttributeName = this.alreadyFilteredAttributeName;
		boolean hasAlreadyFilteredAttribute = request.getAttribute(alreadyFilteredAttributeName) != null;

        // 已经过滤过了
		if (hasAlreadyFilteredAttribute) {
			if (DispatcherType.ERROR.equals(request.getDispatcherType())) {
				doFilterNestedErrorDispatch(httpRequest, httpResponse, filterChain);
				return;
			}
			// Proceed without invoking this filter...
			filterChain.doFilter(request, response);
		}
        // 还未过滤
		else {
			// Do invoke this filter...
			request.setAttribute(alreadyFilteredAttributeName, Boolean.TRUE);
			try {
				doFilterInternal(httpRequest, httpResponse, filterChain);
			}
			finally {
				// Remove the "already filtered" request attribute for this request.
				request.removeAttribute(alreadyFilteredAttributeName);
			}
		}
	}

我们来看这个doFilterInternal方法。（SessionRepositoryFilter类中的方法）这里采用了装饰器模式，将HttpServletRequest和HttpServletResponse封装成SessionRepositoryRequestWrapper和SessionRepositoryResponseWrapper。在这两个Wrapper中对tomcat的session进行了替换。

	@Override
	protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
			throws ServletException, IOException {
		request.setAttribute(SESSION_REPOSITORY_ATTR, this.sessionRepository);

		SessionRepositoryRequestWrapper wrappedRequest = new SessionRepositoryRequestWrapper(request, response);
		SessionRepositoryResponseWrapper wrappedResponse = new SessionRepositoryResponseWrapper(wrappedRequest,
				response);

		try {
			filterChain.doFilter(wrappedRequest, wrappedResponse);
		}
		finally {
			wrappedRequest.commitSession();
		}
	}