Spring Boot + Shiro 实现 Session 持久化实现思路及遗留问题

目录

引言

项目场景

应用技术

实现思路

问题暴露

解决方案

本人理解

引言

Session 为什么需要持久化？

Session 持久化的应用场景很多，诸如：

• 满足分布式：Session 作为有状态会话，体现在 Sessionid 与生成 Session 的服务器参数相关，在实现机理上不支持分布式部署。考虑以下场景：A、B服务器负载均衡共同提供服务，导致用户在 A 机器上登陆认证后不久由于负载均衡将请求转发至 B 服务器上，B 服务器不能验证 A 机器生成的SessionId，用户需要重新登陆，体验极差！可以通过持久化至同一数据库服务器或 Redis 服务器来实现分布式。另外提一句，应用 JWT 这种无状态会话可以实现分布式，但安全性不能保证，可以利用OAuth2保证认证参数安全。
• 获取在线人数：根据并发数选择负载均衡或流量控制。
• 控制用户同时登陆设备的个数：用户账号可能同时通过多个设备登陆，系统是否允许多设备登陆，是否对同一账号的登陆设备数有限制，多设备登陆需要用户信息同步，同步模式（主动推送/被动触发）。
• 在线踢人：当用户行为异常，系统将指定用户的会话信息关闭，实现踢人效果；当登陆设备数超出系统限制时，系统可能选择保留最近最后的登陆设备上的会话信息，踢出之前在线的用户会话。
• 删除用户账号：管理员删除正在登陆的用户账号，删除成功后应将该用户踢出。
• 用户信息管控：Session 作为用户会话的全局变量，可以保存用户信息，通过查询 Session 获