黑马点评--基于Redis实现共享session登录

集群的session共享问题分析

session共享问题：多台Tomcat无法共享session存储空间，当请求切换到不同Tomcat服务时，原来存储在一台Tomcat服务中的数据，在其他Tomcat中是看不到的，这就导致了导致数据丢失的问题。

虽然系统为单体式的架构，但是为了将来应对并发要做水平扩展，部署多个形成负载均衡的集群。

当请求进入nignx会在多台Tomcat之间做一个轮询，每一个Tomcat都有自己的session空间，假设用户请求第一次被负载均衡到了Tomcat1，去发送验证码或者登录时所获取到的用户信息仅仅是保存到这一台Tomcat里了，当用户第二次来执行某些业务被负载均衡到了第二台Tomcat服务上，当该服务要去获取验证码或者用户信息时，而他自身的session内存空间空无一物，这时服务就会中断。

这就是session共享问题。

解决方案：

在初期，为了解决session共享问题，官方提供了session拷贝功能，多台Tomcat之间只要做好一些配置，它们之间就可以互相实现一个数据拷贝，但数据拷贝也有不小的问题，首先就是多台Tomcat保存相同的数据，浪费内存空间，其次拷贝数据是需要时间的，这就造成了时间延迟，在这个延迟之间如果有服务来访问，依旧会造成数据不一致的问题。问题太多，该方案就被pass了。

因此就必须寻找到可以替代session的方案，且必须满足：

数据共享
内存存储（因为session是基于内存的，读写效率较高，像登录校验这种业务访问频率较高，需要满足高并发的需求）
键值对结构（session存储较为简单）

这就是Redis，首先redis是在Tomcat以外的一个存储方案，，任意一台Tomcat都能访问到Redis，所以就可以实现数据共享了，就不会出现数据丢失的情况其次Redis就是存储在内存中的，而且性能非常强，并且redis就是键值对类型的数据库，因此我们是可以用redis来代替session。

基于Redis实现共享session登录

业务流程

如果要使用Redis来代替session，那么前面的短信登录业务也有相应的变化。

比如在发送验证码的业务流程中，需要将验证码存入redis，并且还需要考虑value是什么类型的数据结构，存入验证码时就可以直接用String类型即可。

而key类型就不能和原先一致，因为session在发送请求的时候都有一个独立的session，在Tomcat服务中维护了很多session，那么不同浏览器携带的手机号请求服务时都有着自己独立的session，这些服务都是使用code作为key，但是互相之间互不干扰。

在使用session时，不需要考虑取数据的问题，因为Tomcat会自动的帮助我们去维护session：浏览器发去请求时，Tomcat就为浏览器新建一个session，如果session存在，直接使用即可，在创建session时，就会自动创建sessionID写入到对应浏览器的cookie中，以后浏览器的每次请求就会带着cookie，带着sessionID,这样就能精确找到对应的session，也不用去考虑取的问题。

但redis是一个共享的内存空间，不管是哪个服务发请求，都是往redis的内存空间存储的，如果每个服务使用的key都是code，就会相互覆盖，就会造成数据丢失。而必须要确保每次不同服务访问的key都不同。

那既然如此，那就直接将手机号码作为每个服务的key，这样就能保证每个服务都有自己不同的key，这样的操作也有助于将来我们去获取验证码进行验证。

现在要使用redis，没有维护，现在以手机为key存入进去，那浏览器做登录时还需要带着这个key的值来取，才可以验证。

而在等短信验证码登录注册时，需要将手机号码与验证码存入，正好可以根据手机号码去拿到value。

再去根据手机号查询用户，如果用户存在，则将用户存入redis中。

此时需要考虑两个问题，一是value的数据类型选择问题，二是考虑key的命名，

在短信登录业务存入的是Java对象，那么redis的value虽然可以使用string类型，用json字符串保存，比较直观，但是无法针对单个字段作出修改，只能修改整个字段。

这时可以使用hash类型，hash结构可以将对象中的每个字段独立存储，可以针对单个字段做修改，并且内存占用更少（Hash结构只需要保存数据本身即可，但是String类型还需要保存json字符串的格式）。

如果从优化角度来看，比较推荐Hash结构。

而key的要求也有两点：一是唯一性，二是较为便携。

这里推荐使用随机的token（随机字符串，可以使用UUID来生成）作为key存储用户数据。

而在登录校验这一业务中，以前使用session时的登录凭证就是sessionID，被存在浏览器的cookie中被一直携带，且一直被Tomcat维护。

而现在使用的redis来代替session，则我们使用的随机token则是登录凭证，也就意味着以后浏览器来访问我们需要携带token将其作为凭证。而Tomcat不会将其自动的写入浏览器中，我们需要手动的将其返回前端，那么此处流程就产生了变化。

那当服务器拿到token之后，我们就可以基于token来从redis获取用户信息，剩下校验登录状态流程就不变

而登录凭证是通过前端的逻辑代码进行接收并保留的，在前端使用axios的拦截器，利用拦截器将用户token放在“authorization”头，这样每一条用户请求就会携带token。如果我们使用手机号码作为key去保存，将来返回到前端直接保存在浏览器会有泄漏的风险。这就是我们key不能再次使用手机号码的原因。

代码修改

发送验证码

 @Override
 public Result sendCode(String phone, HttpSession session) {
     //1.校验手机号
     if (RegexUtils.isPhoneInvalid(phone)) {
         //2.如果不符合，返回错误信息
         return Result.fail("手机号格式错误");
     }
     //3.如果符合，生成验证码
     String code = RandomUtil.randomNumbers(6);
     //4.保存验证码到redis 还需要给验证码设置有效时间 set key value ex 120
     //一般都会定义一个工具类来保存常量，避免重复及手误
    stringRedisTemplate.opsForValue().set(LOGIN_CODE_KEY+phone,code,LOGIN_CODE_TTL, TimeUnit.MINUTES);
     //5.发送验证码(模拟发送验证码，该业务并未实现)
     log.debug("发送短信验证码成功，验证码：{}",code);
         // 6.返回结果
     return Result.ok();
 }

短信验证码登录注册

 @Override
 public Result login(LoginFormDTO loginForm, HttpSession session) {
     //1.校验手机号
     String phone = loginForm.getPhone();
     if (RegexUtils.isPhoneInvalid(phone)) {
         //2.如果不符合，返回错误信息
         return Result.fail("手机号格式错误");
     }
     //2.从Redis中获取验证码并校验
     String cacheCode = stringRedisTemplate.opsForValue().get(LOGIN_CODE_KEY + phone);
     String code = loginForm.getCode();
     // 一般校验时，从反向校验，这种校验不需要if嵌套，否则会嵌套if,避免if嵌套过深
     if (cacheCode == null || !cacheCode.equals(code)){
         //3.不一致，返回错误信息
         return Result.fail("验证码错误");
     }
     //4.一致，根据手机号查询用户 select   * from user where phone = ?
     User user = query().eq("phone", phone).one();
     //5.判断用户是否存在
     if (user == null){
         //6.不存在，创建新用户并保存
         // 方法定义在函数中 创建用户
         //在创建完用户到数据库后还需要保存在session中，所以直接赋值给user
         user = createUserWithPhone(phone);
     }
     //7.保存用户信息到redis,
     //7.1随机生成token，作为登录令牌
     String token = UUID.randomUUID().toString(true);
     //7.2将user对象转换为hash存储
     UserDTO userDTO = BeanUtil.copyProperties(user, UserDTO.class);
     //7.3存储到redis中 利用工具类将userDTO转为map
     stringRedisTemplate.opsForHash().putAll(LOGIN_USER_KEY+token,BeanUtil.beanToMap(userDTO));
     // 7.4设置token有效期
     stringRedisTemplate.expire(LOGIN_USER_KEY+token,LOGIN_USER_TTL,TimeUnit.MINUTES);
     //7.4返回token给客户端
     return Result.ok(token);
 }

问题提出：

在之前使用session时，session的有效期是30分钟，但session的有效期是指只要一直在访问session，那么session的有效期就一直是30分钟，只有超过30分钟不访问session，session才会失效。

但是redis的有效时间就是从新建到移除的时间，不在乎是否访问，这样就有弊端。

应该像session一样，只要用户在访问，就应该更新有效时间（即Redis中的token有效期），但是Redis无法得知用户有没有访问服务端，也无法得知用户何时访问服务端。

而在登录拦截校验中，我们所有的请求访问时都要经过拦截器的拦截与校验，只要经过了这个校验，就能证明该浏览器是一个正在活跃着的用户，这是我们就可以更新redis的有效期。

这样就可以做到和session一样的效果，只要有浏览器访问服务端，那么Redis就会去更新token的有效期。所以在接下来修改登录拦截校验代码时还需要添加更新token有效期的逻辑。

代码如下：

 public class LoginInterceptor implements HandlerInterceptor {
     private StringRedisTemplate stringRedisTemplate;
     public LoginInterceptor(StringRedisTemplate stringRedisTemplate) {
         this.stringRedisTemplate = stringRedisTemplate;
     }
     // 前置拦截器
     @Override
     public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
         // 1.获取请求头中的token
         String token = request.getHeader("authorization");
         // 判断是否存在
         if (StrUtil.isBlank(token)) {
             response.setStatus(401);
             return false;
         }
         //  2.以token为key获取redis的用户
         Map<Object, Object> userMap = stringRedisTemplate.opsForHash().entries(LOGIN_USER_KEY + token);
         //  3.判断用户是否存在
         if (userMap.isEmpty()) {
             //  4.不存在 拦截器拦截 返回401状态码 未授权
             response.setStatus(401);
             return false;
         }
         //5.将查询到的Hash数据转换为UserDTO对象
         UserDTO userDTO = BeanUtil.fillBeanWithMap(userMap, new UserDTO(), false);
         //  6.存在，保存用户信息到ThreadLocal
         // 在工具类中定义了一个UserHolder 是一个线程安全的ThreadLocal变量，用于保存当前线程的用户信息。
         // 其中有三个方法：saveUser（ 保存），getUser（拿到），removeUser（移除）。
         UserHolder.saveUser(userDTO);
         //7.刷新token有效期
         stringRedisTemplate.expire(LOGIN_USER_KEY+token, LOGIN_USER_TTL, TimeUnit.MINUTES);
         //8.放行
         return true;
     }
 
     //  拦截器 后处理
     @Override
     public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        //  移除用户 避免用户泄漏
         UserHolder.removeUser();
     }
 }

修改成功，

测试结果：

报错，类强制转换异常ClassCastException，redis serializer报错 long类型不能转换成String类型，在UserServiceImpl中向redis存入用户信息时报错，userMap来自userDTO，userDTO中的id为long类型，无法存储到redis中去，因为我们使用的RedisTemplate为StringRedisTemplate，他要求key与value都必须是string类型，但userMap中的id为long类型，因此报错。

解决方案：

自己在重写toMap函数，在将userDTO转换成userMap时将值的类型转换成string字符串
提供的工具类有自定义的功能，如下所示

 Map<String, Object> userMap = BeanUtil.beanToMap(userDTO,new HashMap<>(),
         CopyOptions.create().setIgnoreNullValue(true).
                 setFieldValueEditor((fieldName,fieldValue)->fieldValue.toString()));

再次测试：

解决状态登录刷新的问题

问题引入：

目前的短信登录拦截器无法做到只要用户一直登陆就不会过期。

因为拦截器拦截的不是一切路径，而是那些需要登录校验的路径，比如user/me,或者将来用户的下单，支付这样一些对用户信息有需求的路径，或者说被拦截器拦截的路径，但拦截器并不是拦截一切。

如果用户一直访问的是不需要登录的页面，比如首页或者商户详情页，这些不需要登录校验就可以看，这些就不会去刷新有效期，过了指定的有效期后，即使用户还在访问，但token就会被移除，问题因此出现。

解决方案：

在原有拦截器的基础上再加上一个拦截器，这样用户请求就要先经过第一个拦截器，在经过第二个，第一个拦截器拦截全部路径，所有请求都会被拦截，就可以在这个拦截器中做刷新token有效期的业务（获取token，查询Redis用户，保存到ThreadLocal中，刷新token有效期，放行），第一个拦截器不做拦截，这样就可以确保一切请求都可以触发刷新的动作，第二个拦截器只需要做拦截业务（查询ThreadLocal的用户，不存在则拦截，存在，则继续）即可

代码展示：

LoginInterceptor.java

 public class LoginInterceptor implements HandlerInterceptor {
     // 前置拦截器
     @Override
     public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
       //1.判断是否需要拦截（ ThreadLocal中是否有用户）
         if (UserHolder.getUser() == null) {
             //  2.没有，拦截，返回401
             response.setStatus(401);
             return false;
         } else {
             // 有用户，放行
             return true;
         }
     }

RefreshTokenInterceptor.java

 public class RefreshTokenInterceptor implements HandlerInterceptor {
     private StringRedisTemplate stringRedisTemplate;
 
     public RefreshTokenInterceptor(StringRedisTemplate stringRedisTemplate) {
         this.stringRedisTemplate = stringRedisTemplate;
     }
 
     // 前置拦截器
     @Override
     public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
         // 1.获取请求头中的token
         String token = request.getHeader("authorization");
         // 判断是否存在
         if (StrUtil.isBlank(token)) {
             return true;
         }
         //  2.以token为key获取redis的用户
         Map<Object, Object> userMap = stringRedisTemplate.opsForHash().entries(LOGIN_USER_KEY + token);
         //  3.判断用户是否存在
         if (userMap.isEmpty()) {
             //  4.不存在 拦截器拦截 返回401状态码 未授权
            return true;
         }
         //5.将查询到的Hash数据转换为UserDTO对象
         UserDTO userDTO = BeanUtil.fillBeanWithMap(userMap, new UserDTO(), false);
         //  6.存在，保存用户信息到ThreadLocal
         // 在工具类中定义了一个UserHolder 是一个线程安全的ThreadLocal变量，用于保存当前线程的用户信息。
         // 其中有三个方法：saveUser（ 保存），getUser（拿到），removeUser（移除）。
         UserHolder.saveUser(userDTO);
         //7.刷新token有效期
         stringRedisTemplate.expire(LOGIN_USER_KEY + token, LOGIN_USER_TTL, TimeUnit.SECONDS);
         //8.放行
         return true;
     }
 
     //  拦截器 后处理
     @Override
     public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
         //  移除用户 避免用户泄漏
         UserHolder.removeUser();
     }
 }

装配拦截器：

@Configuration
 public class MvcConfig implements WebMvcConfigurer {
     @Resource
     private StringRedisTemplate stringRedisTemplate;
     @Override
     public void addInterceptors(InterceptorRegistry registry) {
         //  登录拦截器
        registry.addInterceptor(new LoginInterceptor())
                //  除了这些路径，其他路径都进行拦截
                .excludePathPatterns(
                        "/user/code",
                        "/user/login",
                        "/blog/hot",
                        "/voucher/**",
                        "/shop/**",
                        "/shop-type/**",
                        "/upload/**",
                        "/blog/query/hot",
                        "/druid/**"
                ).order(1);
        // token刷新拦截器
 registry.addInterceptor(new RefreshTokenInterceptor(stringRedisTemplate))
         .addPathPatterns("/**").order(0);
     }
 }

如何控制拦截器的前后顺序：在源码中order的值越大，优先级越低，值越小，优先级越高。

测试成功，无论访问哪个页面，都会刷新token的有效期。

至此，基于Redis实现共享session登录的业务完成。

总结：基于Redis改造短信登录，改造的点如下：

发送短信验证码时将验证码存入redis中，key使用的是手机号码，value的类型为String
短信登录时保存用户到Redis，key要保证唯一以及便携，因此将key设为了UUID，放在了前端的请求头中，返回给了用户，保存到浏览器中，这样一来浏览器可以携带token来访问服务端，从而实现登陆的效果。

注意事项：