SpringSession
分布式下Session共享问题解决方案
1、session复制
优点: web-server(Tomcat) 原生支持,只需修改配置文件
缺点:session同步需要数据传输,占用大量网络带宽,降低了服务器群的业务处理能力;任意一台web-server保存的数据都是所有web-server的session总和,受到内存限制无法水平拓展更多的web-server;大型分布式集群情况下,由于所有web-server都全量保存数据,所以此方案不可取
2、客户端存储
优点:服务器不需要存储session,用户保存自己的session信息到cookie中。节省服务端资源
缺点:都是缺点,这只是一种思路。具体如下
每次http请求,携带用户在cookie中的完整信息,浪费网络带宽;cookie有长度限制4k,不能保存大量信息;session数据放在cookie中,存在泄露、篡改、窃取等安全隐患,这种方式不会使用
3、hash一致性
根据用户的IP进行判断,只要客户端的ip不变或者hash值取值不变,就会一直访问同一台服务器。
优点:只需要修改nginx配置,不需要修改应用代码;负载均衡,只要hash属性的值分布是均匀的,多台web-server的负载是均衡的;可以支持web-server水平拓展(session同步法是不行的,受内存限制)
缺点:session还是存在web-server中,所以web-server重启可能导致部分session丢失,影响业务,如部分用户需要重新登录;如果web-server水平扩展,rehash后session重新分布,也会有一部分用户路由不到正确的session
但是以上的缺点问题也不是很大,因为session本来都是有有效期的。所以这两种反向代理的方式可以使用
4、统一存储
由后端统一存储session,使用DB/Redis
优点:没有安全隐患;可以水平扩展,数据库/缓存水平切分即可;web-server重启或者扩容都不会有session丢失
缺点:增加了一次网络调用,并且需要修改应用代码;如将所有的getSession方法替换为从Redis查数据的方式。redis获取数据比直接从内存获取慢很多
上面的缺点可以用SpringSession完美解决
5、SpringSession
配置:存储类型:spring.session.store-type=redis
超时时间:server.servlet.session.timeout=30m
@EnableRedisHttpSession标在主类上
默认发的令牌作用域是当前域:需要解决子域共享问题,及应使用json的序列化方式序列化数据
@Configuration
public class GulimallSessionConfig {
@Bean
public CookieSerializer cookieSerializer() {
DefaultCookieSerializer cookieSerializer = new DefaultCookieSerializer();
//放大作用域
cookieSerializer.setDomainName("gulimall.com");
cookieSerializer.setCookieName("GULISESSION");
return cookieSerializer;
}
@Bean
public RedisSerializer<Object> springSessionDefaultRedisSerializer() {
return new GenericJackson2JsonRedisSerializer();
}
}