java学习(day32) - 技术栈

该项目来自于黑马程序员的Redis课程里面的一个实战项目

1、短信登录

1.1、导入黑马点评项目

1.1.1 、导入SQL

在这个地方我们导入数据库时候产生了报错

这是因为之前苍穹外卖时候，他这个sql语句里面

有这个建表语句

而这次点评项目sql里面没有建表语句

所以我们可以先写一个建表语句

复制代码

CREATE DATABASE IF NOT EXISTS hmdp;
USE hmdp;

然后选好数据库就能导入了

.1.2、有关当前模型

手机或者app端发起请求，请求我们的nginx服务器，nginx基于七层模型走的事HTTP协议，可以实现基于Lua直接绕开tomcat访问redis，也可以作为静态资源服务器，轻松扛下上万并发，负载均衡到下游tomcat服务器，打散流量，我们都知道一台4核8G的tomcat，在优化和处理简单业务的加持下，大不了就处理1000左右的并发，经过nginx的负载均衡分流后，利用集群支撑起整个项目，同时nginx在部署了前端项目后，更是可以做到动静分离，进一步降低tomcat服务的压力，这些功能都得靠nginx起作用，所以nginx是整个项目中重要的一环。

在tomcat支撑起并发流量后，我们如果让tomcat直接去访问Mysql，根据经验Mysql企业级服务器只要上点并发，一般是16或32 核心cpu，32 或64G内存，像企业级mysql加上固态硬盘能够支撑的并发，大概就是4000起~7000左右，上万并发，瞬间就会让Mysql服务器的cpu，硬盘全部打满，容易崩溃，所以我们在高并发场景下，会选择使用mysql集群，同时为了进一步降低Mysql的压力，同时增加访问的性能，我们也会加入Redis，同时使用Redis集群使得Redis对外提供更好的服务。

1.1.3、导入后端项目

在资料中提供了一个项目源码：

1.1.4、导入前端工程

1.1.5 运行前端项目

1.2 、基于Session实现登录流程

发送验证码：

用户在提交手机号后，会校验手机号是否合法，如果不合法，则要求用户重新输入手机号

如果手机号合法，后台此时生成对应的验证码，同时将验证码进行保存，然后再通过短信的方式将验证码发送给用户

短信验证码登录、注册：

用户将验证码和手机号进行输入，后台从session中拿到当前验证码，然后和用户输入的验证码进行校验，如果不一致，则无法通过校验，如果一致，则后台根据手机号查询用户，如果用户不存在，则为用户创建账号信息，保存到数据库，无论是否存在，都会将用户信息保存到session中，方便后续获得当前登录信息

校验登录状态:

用户在请求时候，会从cookie中携带者JsessionId到后台，后台通过JsessionId从session中拿到用户信息，如果没有session信息，则进行拦截，如果有session信息，则将用户信息保存到threadLocal中，并且放行

实现发送短信验证码功能

页面流程

具体代码如下

贴心小提示：

具体逻辑上文已经分析，我们仅仅只需要按照提示的逻辑写出代码即可。

发送验证码

我们是把这个主要功能放到service里面去做

UserServiceImpl

复制代码

@Override
public Result sendCode(String phone, HttpSession session) {
    // 1.校验手机号
    if (RegexUtils.isPhoneInvalid(phone)) {
        // 2.如果不符合，返回错误信息
        return Result.fail("手机号格式错误！");
    }
    // 3.符合，生成验证码
    String code = RandomUtil.randomNumbers(6);

    // 4.保存验证码到 session
    session.setAttribute("code",code);
    // 5.发送验证码
    log.debug("发送短信验证码成功，验证码：{}", code);
    // 返回ok
    return Result.ok();
}

2. 校验手机号

Java

复制代码

// 1.校验手机号
if (RegexUtils.isPhoneInvalid(phone)) {
    // 2.如果不符合，返回错误信息
    return Result.fail("手机号格式错误！");
}

这里调用了一个叫 RegexUtils 的工具类（通常里面封装了正则表达式）来判断手机号格式对不对（比如是不是 11 位、是不是 1 开头）。
如果 isPhoneInvalid 返回 true（无效手机号），就直接打断后续操作，返回给前端一个带有错误提示的 Result.fail。这一步是为了防止乱填数据，并节省调用真实短信接口的费用。

3. 生成验证码

Java

复制代码

// 3.符合，生成验证码
String code = RandomUtil.randomNumbers(6);

代码走到这里，说明手机号没问题。
调用 RandomUtil（通常是 Hutool 等开源工具包里的类）生成一个 6位数的随机纯数字 字符串，并赋值给变量 code。

4. 保存验证码

Java

复制代码

// 4.保存验证码到 session
session.setAttribute("code",code);

这是非常关键的一步！ 为什么要存起来？因为等会儿用户收到短信后，要把验证码填在网页上发回来。服务器必须记住刚才发给这个用户的验证码是多少，才能进行对比校验。
session 就像是服务器为当前用户开的一个"私人储物柜"。这行代码把生成的 code 放进了储物柜，并贴上了一个叫 "code" 的标签。

5. 模拟发送并返回结果

Java

复制代码

// 5.发送验证码
log.debug("发送短信验证码成功，验证码：{}", code);
// 返回ok
return Result.ok();

这里就是您上一题问到的日志代码。在真实的商业项目中，这里应该是一段调用阿里云、腾讯云等短信服务商 API 的代码。但为了本地测试方便和省钱，这里直接用日志打印来模拟发送成功。
最后，返回 Result.ok() 告诉前端："一切顺利，验证码已经发了，你提示用户注意查收吧"。
登录

UserServiceImpl

复制代码

@Override
public Result login(LoginFormDTO loginForm, HttpSession session) {
    // 1.校验手机号
    String phone = loginForm.getPhone();
    if (RegexUtils.isPhoneInvalid(phone)) {
        // 2.如果不符合，返回错误信息
        return Result.fail("手机号格式错误！");
    }
    // 3.校验验证码
    Object cacheCode = session.getAttribute("code");
    String code = loginForm.getCode();
    if(cacheCode == null || !cacheCode.toString().equals(code)){
        //3.不一致，报错
        return Result.fail("验证码错误");
    }
    //一致，根据手机号查询用户
    User user = query().eq("phone", phone).one();

    //5.判断用户是否存在
    if(user == null){
        //不存在，则创建
        user =  createUserWithPhone(phone);
    }
    //7.保存用户信息到session中
    session.setAttribute("user",user);

    return Result.ok();
}

然后就在下面创建一个createUserWithphone的方法

复制代码

private User createUserWithPhone(String phone) {
    // 1. 创建用户
    User user = new User();
    user.setPhone(phone);
    user.setNickName(USER_NICK_NAME_PREFIX + RandomUtil.randomString(10));
    // 2. 保存用户
    save(user);
    return user;
}

这个save就是mybatisplus 的提供的一个方法，它的作用就和insert一样

mybatisPlus 初窥门径

这里面用到了mybati splus ，下面我们来好好讲讲这个东西

你可以把 MyBatis-Plus 理解为 MyBatis 的"超级外挂"或"增强包" 。它底层依然是 MyBatis，但它帮你把单表的"增删改查"全自动写好了，你再也不用为了写一个简单的 SELECT * FROM ... WHERE ... 去建 XML 文件或者写 @Select 注解了。

下面我为你把这段代码和类声明"翻译"成你能秒懂的 MyBatis 逻辑。

1. 拆解这段代码干了啥

Java

复制代码

// 一致，根据手机号查询用户
User user = query().eq("phone", phone).one();

如果只用原生 MyBatis，为了实现这个功能，你需要做三件事：

在 UserMapper.java 里写：User selectByPhone(String phone);
在 UserMapper.xml 里写：<select id="selectByPhone" resultType="User"> SELECT * FROM tb_user WHERE phone = #{phone} </select>
在 Service 里调用：userMapper.selectByPhone(phone);

但是用了 MyBatis-Plus，上面的 1 和 2 全都省了！你只需要写这一行代码。

它的链式调用翻译过来就是：

query(): 告诉框架，"我要开始构建一个查询条件了"。
.eq("phone", phone): eq 是 equals（等于）的缩写。意思是 SQL 里的 WHERE phone = #{phone}。也就是 eq(数据库列名, 要匹配的值)
.one(): 告诉框架，"执行这个查询，并且我确信结果最多只有一条，请给我返回一个 User 对象（如果找不到就返回 null）"。既然有.one()那就有.list 意思就是返回一个list集合

2. 为什么要继承 ServiceImpl**？泛型又是什么意思？**

这个是mybaitsplus 提供的可以帮助我们实现单表的增删改查

之前我记得usermapper 还会写一点方法，现在还需写吗

你记得非常准确！以前用原生 MyBatis 的时候，UserMapper 里面密密麻麻写满了各种增删改查的方法。

现在用了 MyBatis-Plus，绝大多数情况下你不需要写方法了，但遇到特殊情况依然要手写。

我们可以把情况分为两类：

1. 什么时候不需要写任何方法？（大约占日常开发的 80%~90%）

只要你的业务需求是单表操作（只操作 tb_user 这一张表），你就不需要在 UserMapper 里写哪怕一行代码。

因为你继承的 BaseMapper<User> 已经默默帮你写好了几十个常用的方法，比如：

insert(user) (新增用户)
deleteById(id) (根据ID删除)
updateById(user) (根据ID更新)
selectById(id) (根据ID查询)
selectList(queryWrapper) (条件查询/列表查询)

所以，在处理这些常规需求时，你的 UserMapper 就是一个干干净净的"空壳"：

Java

复制代码

@Mapper
public interface UserMapper extends BaseMapper<User> {
    // 里面什么都不用写！这就够了！
}

2. 什么时候依然需要自己写方法？（大约占 10%~20%）

MyBatis-Plus 的设计理念是 "单表 MP 搞定，多表手写 SQL"。当你遇到以下两种情况时，就需要像以前一样在里面写方法了：

场景一：多表联查 (JOIN)

假设你需要查询"某个用户的基本信息，以及他最近购买的订单记录"。这就涉及到了 tb_user 和 tb_order 两张表。MyBatis-Plus 原生不支持多表 JOIN。

这时候，你就要自己动手了：

Java

复制代码

@Mapper
public interface UserMapper extends BaseMapper<User> {
    
    // 你依然可以像以前一样写 @Select 注解
    @Select("SELECT u.*, o.order_no FROM tb_user u JOIN tb_order o ON u.id = o.user_id WHERE u.id = #{userId}")
    List<UserOrderDTO> selectUserWithOrders(Long userId);
}

场景二：非常复杂的单表查询（或性能优化）

有时候单表查询的条件极其复杂（比如一大堆嵌套的 AND 和 OR，或者复杂的聚合函数 GROUP BY、HAVING），如果强行用 MyBatis-Plus 的链式代码（Wrapper）去拼接，代码会变得极其难读。

这时候，为了代码清晰或者专门优化 SQL 性能，我们也会选择退回到原生 MyBatis 的写法，在 Mapper 里定义方法，然后去 XML 文件里写复杂的 SQL。

你提到的类的头部通常长这样：

Java

复制代码

public class UserServiceImpl extends ServiceImpl<UserMapper, User> implements IUserService

为什么要 extends ServiceImpl**？**

你上面能直接调用 query()，或者在其他地方调用 save(user)、removeById(id) 等等这些现成的方法，全是因为你继承了 ServiceImpl。

ServiceImpl 是 MyBatis-Plus 官方提前帮你写好的一个类，里面包含了成百上千行实现增删改查的代码。你一继承它，你的 UserServiceImpl 就瞬间白嫖了所有这些单表操作的方法，不需要自己一行行去写了。

为什么泛型是 <UserMapper, User>****？

既然 ServiceImpl 是官方写好的一个通用类，官方在写这个类的时候，根本不知道未来你会用它来操作"用户表"还是"订单表"，也不知道你的 Mapper 叫什么名字。

所以官方用了泛型，让你在使用时"填空"：

第一个填空位 UserMapper：告诉 ServiceImpl："哥们，当你底层真正需要去操作数据库时，请使用我提供的 UserMapper 这个接口去执行。"（相当于自动帮你做了 @Autowired UserMapper 的注入）。

我们来回忆一下之前纯mybatis的时候

1. 以前（只用原生 MyBatis 时）你是怎么写的

在标准的 Spring + MyBatis 架构中，Service 层需要调用 Mapper 层去查数据库。所以你必须在 Service 类里手动注入 Mapper：

Java

复制代码

@Service
public class UserServiceImpl implements IUserService {

    // 👇 就是这里！你以前一定会写这段代码把 Mapper 注入进来
    @Autowired 
    private UserMapper userMapper;

    @Override
    public void login(String phone) {
        // 然后你才能在方法里使用 userMapper 去查数据库
        User user = userMapper.selectByPhone(phone);
        // ... 其他逻辑
    }
}

如果没有 @Autowired 把 userMapper 拿过来，你在 Service 里根本没法和数据库打交道。

2. 现在（用了 MyBatis-Plus 时）变成了什么样

用了 MyBatis-Plus 之后，你的代码变成了这样：

Java

复制代码

@Service
public class UserServiceImpl extends ServiceImpl<UserMapper, User> implements IUserService {

    // 👆 注意看，这里面干干净净，没有 @Autowired private UserMapper userMapper; 这一行了！

    @Override
    public void login(String phone) {
        // 你直接调用了 query() 就能查数据库
        User user = query().eq("phone", phone).one();
    }
}

💡 核心解密：它是怎么"自动注入"的？

当你写了 extends ServiceImpl<UserMapper, User> 的时候，你继承的那个父类 ServiceImpl 的源码里，其实偷偷写了类似这样的代码：

Java

复制代码

// 这是 MyBatis-Plus 官方源码的简化版
public class ServiceImpl<M extends BaseMapper<T>, T> {

    @Autowired
    protected M baseMapper; // 这里把传进来的 UserMapper 注入了，取名叫 baseMapper

    // 你调用的 query() 方法，底层其实就是在使用这个 baseMapper
}

总结一下： 以前，你是自己当大厨，必须亲自去仓库（Spring 容器）把菜刀（UserMapper）拿过来（ @Autowired**）才能切菜。现在，你继承了一个"全自动厨房（ServiceImpl）"** ，你在门口（泛型 <UserMapper, ...>）告诉厨房："我今天切菜要用那把特定的菜刀"，厨房内部就已经把菜刀给你摆好（自动注入为 baseMapper），你直接喊一声"切菜（query()）"就可以了！

第二个填空位 User：告诉 ServiceImpl："哥们，我们这次要操作的数据表映射的实体类是 User 类。查询结果请帮我封装成 User 对象，新增数据时我也传给你 User 对象。"

💡 总结对照表

|---------------|-----------------------------------|------------------------------------------------|
| 概念 | 原生 MyBatis | MyBatis-Plus |
| Mapper 层 | 自己写接口，自己写 XML/注解 | 继承 BaseMapper<User> ，全自动搞定单表 SQL |
| Service 层 | 注入 Mapper，自己写各种增删改查方法 | 继承 ServiceImpl<UserMapper, User> ，白嫖全套增删改查方法 |
| 根据手机号查询 | userMapper.selectByPhone(phone) | query().eq("phone", phone).one() |

这就是为什么大家爱用 MyBatis-Plus 的原因：少写重复代码，准点下班。 复杂的多表联查（JOIN）你依然可以像以前一样去写 XML，两者完全不冲突！

还有一个

当你写下 ServiceImpl<UserMapper, User> 时，你已经完成了两件大事：

锁定目标： 你告诉框架，这个 Service 处理的实体类是 User。
触发扫描： MyBatis-Plus 在项目启动时，会通过 Java 反射机制（Reflection） 去"解剖"这个 User 类。

框架内部的逻辑大概是这样的：

第一步（找到类）： "哦，泛型里的 T 是 User 类。"
第二步（看头顶）： "我来看看 User 类头顶上有没有贴 @TableName 标签？"
第三步（读取内容）： * 如果有，比如 @TableName("tb_user")，框架就记下："以后这个 Service 发出的 SQL 语句，表名都写 tb_user。"

- 如果没有，框架就启动备份方案："既然没贴名牌，那我就默认表名和类名一样，也叫 user 吧。"

不仅仅是表名

通过泛型找到这个类后，框架还会继续往下扫描类里面的成员变量（Fields）：

看到 @TableId：它就知道了数据库里的主键是哪一列，主键是怎么生成的（比如自增）。
看到普通变量 phone：它就知道了数据库里有一个叫 phone 的列。
看到 @TableField(exist = false)：它就知道了这个变量只是代码里临时用的，不要去数据库里查这一列。

当没有定义注解的时候默认规则

当我们通过注解定义了查哪张表的时候

这里有一个小技巧，找实现这里有两种方式

对着这个ctrl+Alt+B

或者直接点左边绿色I按钮(这个之前常用)

然后在数据库中点击这个ddl也可以直接打开这个建表语句，查看相关的内容

在这里我们加入了mybatis plus的内容

实现登录拦截功能

注意登陆这里是我们自己写到登陆的业务层里面自己拦，后面其它功能，不可能都像登陆这样一个个controller
都这样亲历亲为，所以写一个拦截器全局拦截，然后把登陆功能放行就行了

提到拦截器这里我们又不由的想到过滤器，接下来我们把它们放在一张图片里面再来对比一下

温馨小贴士：tomcat的运行原理

当用户发起请求时，会访问我们像tomcat注册的端口，任何程序想要运行，都需要有一个线程对当前端口号进行监听，tomcat也不例外，当监听线程知道用户想要和tomcat连接连接时，那会由监听线程创建socket连接，socket都是成对出现的，用户通过socket相互相传递数据，当tomcat端的socket接受到数据后，此时监听线程会从tomcat的线程池中取出一个线程执行用户请求，在我们的服务部署到tomcat后，线程会找到用户想要访问的工程，然后用这个线程转发到工程中的controller，service，dao中，并且访问对应的DB，在用户执行完请求后，再统一返回，再找到tomcat端的socket，再将数据写回到用户端的socket，完成请求和响应

通过以上讲解，我们可以得知每个用户其实对应都是去找tomcat线程池中的一个线程来完成工作的，使用完成后再进行回收，既然每个请求都是独立的，所以在每个用户去访问我们的工程时，我们可以使用threadlocal来做到线程隔离，每个线程操作自己的一份数据

温馨小贴士：关于threadlocal

黑马说每一个进入tomcat的请求都是一个独立的线程

如果小伙伴们看过threadLocal的源码，你会发现在threadLocal中，无论是他的put方法和他的get方法，都是先从获得当前用户的线程，然后从线程中取出线程的成员变量map，只要线程不一样，map就不一样，所以可以通过这种方式来做到线程隔离

正是因为 map 不一样，所以最后得到的数据是绝对不一样的

我们通过拦截器校验完成之后，需要把校验后得到结果放在threadlocal里面最后再由threadlocal传给这几个controller

这里面登陆的凭证也就是session_id 实际上就在cookie里面

拦截器代码

我们是把这个拦截器代码写在utils包里面

我们需要重写它的一下方法，但是在这里我们发现一个问题，我们使用alt+enter好像已经不管用了，这是因为

alt+enter只在修复错误时候才管用

这里我就要用到ctlr+i ctrl+O也可以

重写pre方法和after方法

复制代码

public class LoginInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        //1.获取session
        HttpSession session = request.getSession();
        //2.获取session中的用户
        Object user = session.getAttribute("user");
        //3.判断用户是否存在
        if(user == null){
            //4.不存在，拦截，返回401状态码
            response.setStatus(401);
            return false;
        }
        //5.存在，保存用户信息到Threadlocal
        UserHolder.saveUser((User)user);
        //6.放行
        return true;
    }
}

这里黑马漏了一个afterCompletetion

复制代码

@Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        // 移除用户，防止内存泄漏和数据串位
        UserHolder.removeUser();
    }

为什么要加这个，前面那个是要在拦截之前生效，后面这个是

1. 防止"数据串位"（极其严重的安全 Bug）

还记得我们刚才说的吗？Tomcat 里的线程是**"用完即还，重复利用"**的。

假设用户【张三】发起了请求，Tomcat 派出了【线程 A】来接待。拦截器把张三的信息存进了【线程 A】的私有口袋（ThreadLocalMap）里。
请求结束了，如果你不清理口袋，【线程 A】就带着张三的信息回到了线程池待命。
过了一会儿，用户【李四】发起了请求。Tomcat 恰好又把【线程 A】派出去接待李四。
如果后面的代码直接去读 ThreadLocal，系统就会误以为当前操作的人是张三！ 这就导致李四看到了张三的隐私，或者花掉了张三的钱。

所以，必须在每次请求结束时，把口袋翻过来抖干净。

也就是说threadlocha里面的数据我们只在这一次线程里面使用就行了，线程结束就要清空换回线池，不清空，下次别的线程就会看到

从这里其实也回答了为什么通过treadlocal可以做到线程隔离

让拦截器生效

复制代码

@Configuration
public class MvcConfig implements WebMvcConfigurer {

    @Resource
    private StringRedisTemplate stringRedisTemplate;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        // 登录拦截器
        registry.addInterceptor(new LoginInterceptor())
        .excludePathPatterns(
            "/shop/**",
            "/voucher/**",
            "/shop-type/**",
            "/upload/**",
            "/blog/hot",
            "/user/code",
            "/user/login"
        ).order(1);
        // token刷新的拦截器
        registry.addInterceptor(new RefreshTokenInterceptor(stringRedisTemplate)).addPathPatterns("/**").order(0);
    }
}

这里后面的.order(1)是指拦截器执行的顺序

隐藏用户敏感信息

我们通过浏览器观察到此时用户的全部信息都在，这样极为不靠谱，所以我们应当在返回用户信息之前，将用户的敏感信息进行隐藏，采用的核心思路就是书写一个UserDto对象，这个UserDto对象就没有敏感信息了，我们在返回前，将有用户敏感信息的User对象转化成没有敏感信息的UserDto对象，那么就能够避免这个尴尬的问题了

在登录方法处修改

复制代码

//7.保存用户信息到session中
session.setAttribute("user", BeanUtil.copyProperties(user,UserDTO.class));

注意这里和我们之前苍穹外卖学的

BeanUtils.copyProperties(源, 目标)有点不一样，目标这里之前我们不是传字节码对象，而是一个实例化对象

复制代码

// 1. 必须自己手动 new 一个空的目标对象
UserDTO userDTO = new UserDTO(); 
// 2. 将 user 的属性拷贝到 userDTO 中 (注意：没有返回值)
BeanUtils.copyProperties(user, userDTO); 
// 3. 把填满数据的 userDTO 存入 session
session.setAttribute("user", userDTO);

在拦截器处：

复制代码

//5.存在，保存用户信息到Threadlocal
UserHolder.saveUser((UserDTO) user);

在UserHolder处：将user对象换成UserDTO

复制代码

public class UserHolder {
    private static final ThreadLocal<UserDTO> tl = new ThreadLocal<>();

    public static void saveUser(UserDTO user){
        tl.set(user);
    }

    public static UserDTO getUser(){
        return tl.get();
    }

    public static void removeUser(){
        tl.remove();
    }
}

这里有一个小技巧查找用法，看看getUser在哪写地方被用了

这是最标准的查找方式，会在底部打开一个专用的 Find 窗口，方便你慢慢看。

Windows / Linux: Alt + F7

1.6、session共享问题

核心思路分析：

每个tomcat中都有一份属于自己的session,假设用户第一次访问第一台tomcat，并且把自己的信息存放到第一台服务器的session中，但是第二次这个用户访问到了第二台tomcat，那么在第二台服务器上，肯定没有第一台服务器存放的session，所以此时整个登录拦截功能就会出现问题，我们能如何解决这个问题呢？早期的方案是session拷贝，就是说虽然每个tomcat上都有不同的session，但是每当任意一台服务器的session修改时，都会同步给其他的Tomcat服务器的session，这样的话，就可以实现session的共享了

但是这种方案具有两个大问题

1、每台服务器中都有完整的一份session数据，服务器压力过大。

2、session拷贝数据时，可能会出现延迟

所以咱们后来采用的方案都是基于redis来完成，我们把session换成redis，redis数据本身就是共享的，就可以避免session共享的问题了

Redis代替session的业务流程

1.7.1、设计key的结构

首先我们要思考一下利用redis来存储数据，那么到底使用哪种结构呢？由于存入的数据比较简单，我们可以考虑使用String，或者是使用哈希，如下图，如果使用String，同学们注意他的value，用多占用一点空间，如果使用哈希，则他的value中只会存储他数据本身，如果不是特别在意内存，其实使用String就可以啦。

1.7.2、设计key的具体细节

所以我们可以使用String结构，就是一个简单的key，value键值对的方式，但是关于key的处理，session他是每个用户都有自己的session，但是redis的key是共享的，咱们就不能使用code了

在设计这个key的时候，我们之前讲过需要满足两点

1、key要具有唯一性

2、key要方便携带

如果我们采用phone：手机号这个的数据来存储当然是可以的，但是如果把这样的敏感数据存储到redis中并且从页面中带过来毕竟不太合适，所以我们在后台生成一个随机串token，然后让前端带来这个token就能完成我们的整体逻辑了

1.7.3、整体访问流程

当注册完成后，用户去登录会去校验用户提交的手机号和验证码，是否一致，如果一致，则根据手机号查询用户信息，不存在则新建，最后将用户数据保存到redis，并且生成token作为redis的key，当我们校验用户是否登录时，会去携带着token进行访问，从redis中取出token对应的value，判断是否存在这个数据，如果没有则拦截，如果存在则将其保存到threadLocal中，并且放行。

.8 基于Redis实现短信登录

这里具体逻辑就不分析了，之前咱们已经重点分析过这个逻辑啦。

UserServiceImpl代码

复制代码

@Override
public Result login(LoginFormDTO loginForm, HttpSession session) {
    // 1.校验手机号
    String phone = loginForm.getPhone();
    if (RegexUtils.isPhoneInvalid(phone)) {
        // 2.如果不符合，返回错误信息
        return Result.fail("手机号格式错误！");
    }
    // 3.从redis获取验证码并校验
    String cacheCode = stringRedisTemplate.opsForValue().get(LOGIN_CODE_KEY + phone);
    String code = loginForm.getCode();
    if (cacheCode == null || !cacheCode.equals(code)) {
        // 不一致，报错
        return Result.fail("验证码错误");
    }

    // 4.一致，根据手机号查询用户 select * from tb_user where phone = ?
    User user = query().eq("phone", phone).one();

    // 5.判断用户是否存在
    if (user == null) {
        // 6.不存在，创建新用户并保存
        user = createUserWithPhone(phone);
    }

    // 7.保存用户信息到 redis中
    // 7.1.随机生成token，作为登录令牌
    String token = UUID.randomUUID().toString(true);
    // 7.2.将User对象转为HashMap存储
    UserDTO userDTO = BeanUtil.copyProperties(user, UserDTO.class);
    Map<String, Object> userMap = BeanUtil.beanToMap(userDTO, new HashMap<>(),
                                                     CopyOptions.create()
                                                     .setIgnoreNullValue(true)
                                                     .setFieldValueEditor((fieldName, fieldValue) -> fieldValue.toString()));
    // 7.3.存储
    String tokenKey = LOGIN_USER_KEY + token;
    stringRedisTemplate.opsForHash().putAll(tokenKey, userMap);
    // 7.4.设置token有效期
    stringRedisTemplate.expire(tokenKey, LOGIN_USER_TTL, TimeUnit.MINUTES);

    // 8.返回token
    return Result.ok(token);
}

1.9 解决状态登录刷新问题

1.9.1 初始方案思路总结：

在这个方案中，他确实可以使用对应路径的拦截，同时刷新登录token令牌的存活时间，但是现在这个拦截器他只是拦截需要被拦截的路径，假设当前用户访问了一些不需要拦截的路径，那么这个拦截器就不会生效，所以此时令牌刷新的动作实际上就不会执行，所以这个方案他是存在问题的

1.9.2 优化方案

既然之前的拦截器无法对不需要拦截的路径生效，那么我们可以添加一个拦截器，在第一个拦截器中拦截所有的路径，把第二个拦截器做的事情放入到第一个拦截器中，同时刷新令牌，因为第一个拦截器有了threadLocal的数据，所以此时第二个拦截器只需要判断拦截器中的user对象是否存在即可，完成整体刷新功能。

1.9.3 代码

RefreshTokenInterceptor

复制代码

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获取redis中的用户
        String key  = LOGIN_USER_KEY + token;
        Map<Object, Object> userMap = stringRedisTemplate.opsForHash().entries(key);
        // 3.判断用户是否存在
        if (userMap.isEmpty()) {
            return true;
        }
        // 5.将查询到的hash数据转为UserDTO
        UserDTO userDTO = BeanUtil.fillBeanWithMap(userMap, new UserDTO(), false);
        // 6.存在，保存用户信息到 ThreadLocal
        UserHolder.saveUser(userDTO);
        // 7.刷新token有效期
        stringRedisTemplate.expire(key, LOGIN_USER_TTL, TimeUnit.MINUTES);
        // 8.放行
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        // 移除用户
        UserHolder.removeUser();
    }
}

LoginInterceptor

复制代码

public class LoginInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 1.判断是否需要拦截（ThreadLocal中是否有用户）
        if (UserHolder.getUser() == null) {
            // 没有，需要拦截，设置状态码
            response.setStatus(401);
            // 拦截
            return false;
        }
        // 有用户，则放行
        return true;
    }
}