补习系列(15)-springboot 分布式会话原理

目录

  • 一、背景
  • 二、SpringBoot 分布式会话
  • 三、样例程序
  • 四、原理进阶
    • A. 序列化
    • B. 会话代理
    • C. 数据老化
  • 小结

一、背景

在 补习系列(3)-springboot 几种scope 一文中，笔者介绍过 Session的部分，如下：

对于服务器而言，Session 通常是存储在本地的，比如Tomcat 默认将Session 存储在内存(ConcurrentHashMap)中。

但随着网站的用户越来越多，Session所需的空间会越来越大，同时单机部署的 Web应用会出现性能瓶颈。
这时候需要进行架构的优化或调整，比如扩展Web 应用节点，在应用服务器节点之前实现负载均衡。

那么，这对现有的会话session 管理带来了麻烦，当一个带有会话表示的Http请求到Web服务器后，需求在请求中的处理过程中找到session数据，
而 session数据是存储在本地的，假设我们有应用A和应用B，某用户第一次访问网站，session数据保存在应用A中；
第二次访问，如果请求到了应用B，会发现原来的session并不存在！

一般，我们可通过集中式的 session管理来解决这个问题，即分布式会话。

[图 - ] 分布式会话

二、SpringBoot 分布式会话

在前面的文章中介绍过Redis 作为缓存读写的功能，而常见的分布式会话也可以通过Redis来实现。
在SpringBoot 项目中，可利用spring-session-data-redis 组件来快速实现分布式会话功能。

引入框架

<!-- redis -->
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-data-redis</artifactId>
   <version>${spring-boot.version}</version>
</dependency>
<!-- redis session -->
<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
    <version>1.3.3.RELEASE</version>
</dependency>

同样，需要在application.properties中配置 Redis连接参数：

spring.redis.database=0
spring.redis.host=127.0.0.1
spring.redis.password=
spring.redis.port=6379
spring.redis.ssl=false
#
## 连接池最大数
spring.redis.pool.max-active=10
## 空闲连接最大数
spring.redis.pool.max-idle=10
## 获取连接最大等待时间(s)
spring.redis.pool.max-wait=600

接下来，我们需要在JavaConfig中启用分布式会话的支持：

@Configuration
@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 24
        * 3600, redisNamespace = "app", redisFlushMode = RedisFlushMode.ON_SAVE)
public class RedisSessionConfig {

属性解释如下：

属性 说明
maxInactiveIntervalInSeconds 指定时间内不活跃则淘汰
redisNamespace 名称空间(key的部分)
redisFlushMode 刷新模式

至此，我们已经完成了最简易的配置。

三、样例程序

通过一个简单的例子来演示会话数据生成：

@Controller
@RequestMapping("/session")

@SessionAttributes("seed")
public class SessionController {

    private static final Logger logger = LoggerFactory.getLogger(SessionController.class);

    /**
     * 通过注解获取
     *
     * @param counter
     * @param response
     * @return
     */
    @GetMapping("/some")
    @ResponseBody
    public String someSession(@SessionAttribute(value = "seed", required = false) Integer seed, Model model) {

        logger.info("seed:{}", seed);

        if (seed == null) {
            seed = (int) (Math.random() * 10000);
        } else {
            seed += 1;
        }
        model.addAttribute("seed", seed);

        return seed + "";
    }

上面的代码中，我们声明了一个seed属性，每次访问时都会自增(从随机值开始)，并将该值置入当前的会话中。
浏览器访问 http://localhost:8090/session/some?seed=1，得到结果：

2153
2154
2155
...

此时推断会话已经写入 Redis，通过后台查看Redis，如下：

127.0.0.1:6379> keys *
1) "spring:session:app:sessions:expires:732134b2-2fa5-438d-936d-f23c9a384a46"
2) "spring:session:app:expirations:1543930260000"
3) "spring:session:app:sessions:732134b2-2fa5-438d-936d-f23c9a384a46"

如我们的预期产生了会话数据。

示例代码可从 码云gitee 下载。
https://gitee.com/littleatp/springboot-samples/

四、原理进阶

A. 序列化

接下来，继续尝试查看 Redis 所存储的会话数据

127.0.0.1:6379> hgetall "spring:session:app:sessions:8aff1144-a1bb-4474-b9fe-593
a347145a6"
1) "maxInactiveInterval"
2) "\xac\xed\x00\x05sr\x00\x11java.lang.Integer\x12\xe2\xa0\xa4\xf7\x81\x878\x02
\x00\x01I\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b
\x02\x00\x00xp\x00\x01Q\x80"
3) "sessionAttr:seed"
4) "\xac\xed\x00\x05sr\x00\x11java.lang.Integer\x12\xe2\xa0\xa4\xf7\x81\x878\x02
\x00\x01I\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b
\x02\x00\x00xp\x00\x00 \xef"
5) "lastAccessedTime"
6) "\xac\xed\x00\x05sr\x00\x0ejava.lang.Long;\x8b\xe4\x90\xcc\x8f#\xdf\x02\x00\x
01J\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x
00\x00xp\x00\x00\x01gtT\x15T"
7) "creationTime"
8) "\xac\xed\x00\x05sr\x00\x0ejava.lang.Long;\x8b\xe4\x90\xcc\x8f#\xdf\x02\x00\x
01J\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x
00\x00xp\x00\x00\x01gtT\x15T"

发现这些数据根本不可读，这是因为，对于会话数据的值，框架默认使用了JDK的序列化！
为了让会话数据使用文本的形式存储，比如JSON，我们可以声明一个Bean：

    @Bean("springSessionDefaultRedisSerializer")
    public Jackson2JsonRedisSerializer<Object> jackson2JsonSerializer() {
        Jackson2JsonRedisSerializer<Object> jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer<>(
                Object.class);

        ObjectMapper mapper = new ObjectMapper();
        mapper.setSerializationInclusion(Include.NON_NULL);
        mapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        jackson2JsonRedisSerializer.setObjectMapper(mapper);
        return jackson2JsonRedisSerializer;
    }

需要 RedisSerializer 定义为springSessionDefaultRedisSerializer的命名，否则框架无法识别。
再次查看会话内容，发现变化如下：

127.0.0.1:6379> hgetall "spring:session:app:sessions:d145463d-7b03-4629-b0cb-97c
be520b7e2"
1) "lastAccessedTime"
2) "1543844570061"
3) "sessionAttr:seed"
4) "7970"
5) "maxInactiveInterval"
6) "86400"
7) "creationTime"
8) "1543844570061"

RedisHttpSessionConfiguration 类定义了所有配置，如下所示：

    @Bean
    public RedisTemplate<Object, Object> sessionRedisTemplate(
            RedisConnectionFactory connectionFactory) {
        RedisTemplate<Object, Object> template = new RedisTemplate<Object, Object>();
        template.setKeySerializer(new StringRedisSerializer());
        template.setHashKeySerializer(new StringRedisSerializer());
        if (this.defaultRedisSerializer != null) {
            template.setDefaultSerializer(this.defaultRedisSerializer);
        }
        template.setConnectionFactory(connectionFactory);
        return template;
    }

可以发现，除了默认的值序列化之外，Key/HashKey都使用了StringRedisSerializer(字符串序列化)

B. 会话代理

通常SpringBoot 内嵌了 Tomcat 或 Jetty 应用服务器，而这些HTTP容器都实现了自己的会话管理。
尽管容器也都提供了会话管理的扩展接口，但实现各种会话管理扩展会非常复杂，我们注意到

spring-session-data-redis依赖了spring-session组件；
而spring-session实现了非常丰富的 session管理功能接口。

RedisOperationsSessionRepository是基于Redis实现的Session读写类，由spring-data-redis提供；
在调用路径搜索中可以发现，SessionRepositoryRequestWrapper调用了会话读写类的操作，而这正是一个实现了HttpServletRequest接口的代理类！

源码片段：

        private S getSession(String sessionId) {
            S session = SessionRepositoryFilter.this.sessionRepository
                    .getSession(sessionId);
            if (session == null) {
                return null;
            }
            session.setLastAccessedTime(System.currentTimeMillis());
            return session;
        }

        @Override
        public HttpSessionWrapper getSession(boolean create) {
            HttpSessionWrapper currentSession = getCurrentSession();
            if (currentSession != null) {
                return currentSession;
            }
            String requestedSessionId = getRequestedSessionId();
            if (requestedSessionId != null
                    && getAttribute(INVALID_SESSION_ID_ATTR) == null) {
                S session = getSession(requestedSessionId);

至此，代理的问题得到了解答：

spring-session 通过过滤器实现 HttpServletRequest 代理；
在代理对象中调用会话管理器进一步进行Session的操作。
这是一个代理模式的巧妙应用！

C. 数据老化

我们注意到在查看Redis数据时发现了这样的 Key

1) "spring:session:app:sessions:expires:732134b2-2fa5-438d-936d-f23c9a384a46"
2) "spring:session:app:expirations:1543930260000"

这看上去与 Session 数据的老化应该有些关系，而实际上也是如此。
我们从RedisSessionExpirationPolicy可以找到答案：

当 Session写入或更新时，逻辑代码如下：

    public void onExpirationUpdated(Long originalExpirationTimeInMilli,
            ExpiringSession session) {
        String keyToExpire = "expires:" + session.getId();
        //指定目标过期时间的分钟刻度(下一分钟)
        long toExpire = roundUpToNextMinute(expiresInMillis(session));

        ...

        long sessionExpireInSeconds = session.getMaxInactiveIntervalInSeconds();

        //spring:session:app:sessions:expires:xxx"
        String sessionKey = getSessionKey(keyToExpire);
        ...
        //spring:session:app:expirations:1543930260000
        String expireKey = getExpirationKey(toExpire);
        BoundSetOperations<Object, Object> expireOperations = this.redis
                .boundSetOps(expireKey);
        //将session标记放入集合
        expireOperations.add(keyToExpire);

             //设置过期时间5分钟后再淘汰
        long fiveMinutesAfterExpires = sessionExpireInSeconds
                + TimeUnit.MINUTES.toSeconds(5);

        expireOperations.expire(fiveMinutesAfterExpires, TimeUnit.SECONDS);
        ...
            this.redis.boundValueOps(sessionKey).expire(sessionExpireInSeconds,
                    TimeUnit.SECONDS);
        }
        //设置会话内容数据(HASH)的过期时间
        this.redis.boundHashOps(getSessionKey(session.getId()))
                .expire(fiveMinutesAfterExpires, TimeUnit.SECONDS);

而为了达到清除的效果，会话模块启用了定时删除逻辑：

    public void cleanExpiredSessions() {
        long now = System.currentTimeMillis();
        //当前刻度
        long prevMin = roundDownMinute(now);
        String expirationKey = getExpirationKey(prevMin);
        //获取到点过期的会话表
        Set<Object> sessionsToExpire = this.redis.boundSetOps(expirationKey).members();
        this.redis.delete(expirationKey);
        //逐个清理
        for (Object session : sessionsToExpire) {
            String sessionKey = getSessionKey((String) session);
            touch(sessionKey); //触发exist命令，提醒redis进行数据清理
        }
    }

于是，会话清理的逻辑大致如下：

  • 在写入会话时设置超时时间，并将该会话记录到时间槽形式的超时记录集合中；
  • 启用定时器，定时清理属于当前时间槽的会话数据。

这里 存在一个疑问：
既然 使用了时间槽集合，那么集合中可以直接存放的是 会话ID，为什么会多出一个"expire:{sessionID}"的键值。
在定时器执行清理时并没有涉及会话数据(HASH)的处理，而仅仅是对Expire键做了操作，是否当前存在的BUG?
有了解的朋友欢迎留言讨论

小结

分布式会话解决了分布式系统中会话共享的问题，集中式的会话管理相比会话同步(Tomcat的机制)更具优势，而这也早已成为了常见的做法。
SpringBoot 中推荐使用Redis 作为分布式会话的解决方案，利用spring-session组件可以快速的完成分布式会话功能。
这里除了提供一个样例，还对spring-session的序列化、代理等机制做了梳理，希望能对读者有所启发。

欢迎继续关注"美码师的补习系列-springboot篇" ，期待更多精彩内容^-^

原文地址：https://www.cnblogs.com/littleatp/p/10128852.html

时间： 2024-10-08 18:21:53

补习系列(15)-springboot 分布式会话原理的相关文章

补习系列(9)-springboot 定时器，你用对了吗

目录 简介 一.应用启动任务 二.JDK 自带调度线程池 三.@Scheduled 定制 @Scheduled 线程池 四.@Async 定制 @Async 线程池 小结 简介 大多数的应用程序都离不开定时器,通常在程序启动时.运行期间会需要执行一些特殊的处理任务. 比如资源初始化.数据统计等等,SpringBoot 作为一个灵活的框架,有许多方式可以实现定时器或异步任务. 我总结了下,大致有以下几种: 使用 JDK 的 TimerTask 使用 JDK 自带调度线程池 使用 Quartz 调度

补习系列(10)-springboot 之配置读取

目录 简介 一.配置样例 二.如何注入配置 1. 缺省配置文件 2. 使用注解 3. 启动参数 还有.. 三.如何读取配置 @Value 注解 Environment 接口 @ConfigurationProperties 注解 四.不同环境中的配置 1. 区别开发.测试.发布环境 2. 声明多配置文件 参考文档 简介 在早前的博客中曾经写过 Spring 程序通过 Bean 映射实现配置信息的读取. 在SpringBoot 框架中读取配置的方式变得非常多样,这导致读者在搜寻资料时反而容易迷糊.

补习系列(21)-SpringBoot初始化之7招式

目录 背景 1. @PostConstruct 注解 2. InitializingBean 接口 3. @Bean initMethod方法 4. 构造器注入 5. ApplicationListener 6. CommandLineRunner 7. ApplicationRunner 测试代码 参考文档 背景 在日常开发时,我们常常需要 在SpringBoot 应用启动时执行某一段逻辑,如下面的场景: 获取一些当前环境的配置或变量 向数据库写入一些初始数据 连接某些第三方系统,确认对方可以

补习系列(1)-springboot项目基础搭建课

[TOC] 前言 springboot 最近火的不行,目前几乎已经是 spring 家族最耀眼的项目了.抛开微服务.技术社区这些推广因素不说,框架本身的确有非常多的优点.比如 更简化的配置,摒除了许多繁杂的xml配置(事实证明,越简单的东西越容易让人记住): 内置Servlet容器,不再依赖外部环境 大量的starter模块,随手拈来 支持热部署 作为一名老程序员来说,仍然需要保持一个积极学习的态度.哎,简单点说就是少点伤感,认清现实.你曾经引以为傲的某某EE 技术已经被颠覆了,赶紧换车道 ..

大神必修课系列之java 分布式架构的原理解析

分布式术语 1.1. 异常 服务器宕机 内存错误.服务器停电等都会导致服务器宕机,此时节点无法正常工作,称为不可用. 服务器宕机会导致节点失去所有内存信息,因此需要将内存信息保存到持久化介质上. 网络异常 有一种特殊的网络异常称为--网络分区 ,即集群的所有节点被划分为多个区域,每个区域内部可以通信,但是区域之间无法通信. 磁盘故障 磁盘故障是一种发生概率很高的异常. 使用冗余机制,将数据存储到多台服务器. 1.2. 超时 在分布式系统中,一个请求除了成功和失败两种状态,还存在着超时状态. 可以

补习系列-springboot 实现拦截的五种姿势

目录 简介 姿势一.使用 Filter 接口 1. 注册 FilterRegistrationBean 2. @WebFilter 注解 姿势二.HanlderInterceptor 姿势三.@ExceptionHandler 注解 姿势四.RequestBodyAdvice/ResponseBodyAdvice RequestBodyAdvice 的用法 ResponseBodyAdvice 用法 姿势五.@Aspect 注解 思考 小结 简介 AOP(面向切面编程)常用于解决系统中的一些耦合

补习系列-springboot 单元测试之道

目录 目标 一.About 单元测试 二.About Junit 三.SpringBoot-单元测试 项目依赖 测试样例 四.Mock测试 五.最后 目标 了解 单元测试的背景 了解如何 利用 springboot 实现接口的测试 了解如何 利用 mokito 做代码的 mock 一.About 单元测试 单元测试其实是一种廉价的技术,是由开发者创建运行测试代码,用于对程序模块(软件设计的最小单位)进行正确性检验的一种做法. 而所谓的最小单元,就是指应用的最小可测试部件. 在面向对象领域,最小单

补习系列-springboot-restful应用

一.目标 了解 Restful 是什么,基本概念及风格: 能使用SpringBoot 实现一套基础的 Restful 风格接口: 利用Swagger 生成清晰的接口文档. 二.Restful 入门 什么是REST 摘自百科的定义:REST即表述性状态转移(英文:Representational State Transfer,简称REST) 是Roy Fielding博士(HTTP规范主要贡献者)在2000年的论文中提出来的一种软件架构风格. 是一种针对网络应用的设计和开发方式,可以降低开发的复杂

死磕 java同步系列之zookeeper分布式锁

问题 (1)zookeeper如何实现分布式锁? (2)zookeeper分布式锁有哪些优点? (3)zookeeper分布式锁有哪些缺点? 简介 zooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,它可以为分布式应用提供一致性服务,它是Hadoop和Hbase的重要组件,同时也可以作为配置中心.注册中心运用在微服务体系中. 本章我们将介绍zookeeper如何实现分布式锁运用在分布式系统中. 基础知识 什么是znode? zooKeeper操作和维护的为一个个数据节点,称为 z