Redis：原理+项目实战——Redis实战1（session实现短信登录（并剖析问题））

‍作者简介：一位大四、研0学生，正在努力准备大四暑假的实习
上期文章：Redis：原理速成+项目实战——Redis的Java客户端
订阅专栏：Redis速成
希望文章对你们有所帮助

关于Redis的学习，我个人比较推荐黑马程序员的，其中他的项目就是一个比较大一点的、前后端分离的社交类项目，但这个项目唯一的缺陷就是它并没有用到微服务架构。
不过它对于Redis的学习跟应用方面还是很全面的，学习不要急于求成，每个架构跟技巧都慢慢来，最好要掌握的深入且透彻才行，微服务架构后续再学。
比较推荐的学习方法：看一遍他的视频，每讲完一个功能，就自己关视频然后去敲出来，中途会遇到的所有BUG也都自行去解决，不建议边看边敲。

Redis实战部分项目介绍

我们需要设计的项目是基于Redis的点评类项目（类似大众点评，这边将会学习一遍黑马程序员的黑马点评项目，然后自行去敲并调试出来），其中包括的功能：

功能	所需技术
短信登录	Redis的共享session应用
商户查询缓存	企业的缓存使用技巧——缓存雪崩、穿透等问题的解决
达人探店	基于List的点赞列表&&基于SortedSet的点赞排行榜
优惠券秒杀	Redis计数器、Lua脚本Redis，分布式锁，Redis的三种消息队列
好友关注	基于Set集合的关注、取关、共同关注、消息推送等功能
附近的商户	Redis的GeoHash的应用
UV统计	Redis的HyperLogLog的统计功能
用户签到	Redis的BitMap数据统计功能

导入黑马点评项目

这边直接给这个项目的数据库跟基础网页的链接，大家自行导入即可：
链接：https://pan.baidu.com/s/13yEGsTUKsXBgvQnD3TFX6w?pwd=azq1
提取码：azq1

其中的主要表有：用户表、用户详情表、商户信息表、商户类型表、用户日记表（tb_blog）、用户关注表（tb_follow）、优惠券表（tb_voucher）、优惠券订单表等。

后端项目直接idea打开，大家只需要自行修改相应的yaml配置即可运行，输入网址：
http://localhost:8081/shop-type/list
运行结果：

如果觉得丑的话，大家可以自行去谷歌下载JSONVIEW插件，会让我们的json格式的数据更加的好看，拓展程序安装链接：
JSONVIEW插件安装链接

接下来启动一下前端项目，直接在nginx所在目录中运行start即可打开：

启动完成以后，我们在刚刚的界面里面，右键检查，选择手机模式：

因为这种类型的社交类项目肯定是APP的，所以我们用手机模式观看会更为便捷。
输入localhost:8080即可看到APP：

这样的页面出来，说明前端后端的交互是没有问题的，现在就可以直接进行业务的开发了。

基于session实现短信登录

其实这个功能相信大家都是做过的，但是其实让我从头开始开发这个功能还是有点费时间的，也当作是我自己复习一下了，而拦截器、隐藏敏感信息这些功能也是企业级开发必不可少的，倒也不难。

流程

发送短信验证码

1、用户提交手机号
2、校验手机号是否合法
3、生成校验码
4、将生成的校验码保存到session中，用户后续的验证
5、发送验证码给用户

短信验证码登录与注册

1、提交手机号和验证码
2、校验验证码
3、根据手机号查询用户信息
4、用户存在就保存到session，不然就创建新用户并保存到数据库，最后也保存到session去

校验登录状态

首先我们要知道怎么基于session进行校验，session是基于cookie的（每一个session的id都会保存到cookie中），当用户访问的时候会携带cookie，所以我们可以根据cookie中的session_id来查询session中是否有这个用户：

1、用户发送请求并携带cookie
2、从session中获取用户
3、判断用户是否存在：
（1）没有这个用户就拦截
（2）有这个用户就保存用户信息到ThreadLocal用于登录缓存（ThreadLocal是一个线程域对象，每一个请求到达服务都会是一个独立线程，直接保存到本地变量会出现并发修改的安全问题，而ThreadLocal会将数据保存到每个线程内部，在线程内部创建一个Map来进行保存），保存完后就放行该用户即可

实现短信发送

简单讲讲前端：


点击发送验证码以后，我们的请求就会发到服务端了：

接下来业务的逻辑就让后端来进行处理，根据这个网址的信息，我们编写对应的接口来处理这个请求。
开发这件事情本身就那一套流程，controller调service层接口，service层的实现类serviceImpl实现功能，然后就是注意功能实现的细节。
Usercontroller：

IUserService：

UserServiceImpl：

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

    @Override
    public Result sendCode(String phone, HttpSession session) {
        //校验手机号，校验过程是需要正则表达式的，但这个过程已经被封装到utils包下面了，直接调用方法就行
        if (RegexUtils.isPhoneInvalid(phone)) {
            //不符合，返回错误信息
            return Result.fail("手机号格式错误");
        }
        //符合，生成6位校验码
        String code = RandomUtil.randomNumbers(6);
        //保存验证码到session
        session.setAttribute("code", code);
        //发送验证码，这一般要用第三方服务，这边就做个简单的日志记录一下就好
        log.debug("成功发送短信验证码：{}", code);
        return Result.ok();
    }
}

验证码登录与注册

涉及到了数据库的单表操作，这边推荐mybatis-plus插件简化我们的开发，使用方式会贴到代码的注解去。
UserController：

IUserService：

UserServiceImpl：

@Override
public Result login(LoginFormDTO loginForm, HttpSession session) {
	//校验手机号
    String phone = loginForm.getPhone();
    if (RegexUtils.isPhoneInvalid(phone)) {
        //不符合，返回错误信息
        return Result.fail("手机号格式错误");
    }
    //校验验证码
    Object cacheCode = session.getAttribute("code");
    String code = loginForm.getCode();
    if (cacheCode == null || !cacheCode.toString().equals(code)){
        //不一致，报错
        return Result.fail("验证码错误");
    }
    //一致，根据手机号查询用户，这里要单表查询
    //mybatis-plus可以帮助我们很快的实现：
    //1、继承类ServiceImpl<实体类的Mapper，实体类>
    //2、实体类中要加入注解@TableName()，表示从哪个数据库取的
    //3、调用query()方法可以直接实现select * from 表
    //4、调用eq方法验证查询出来的数据中，列名为phone的列有没有值与phone相同的
    //5、可以通过one()查询出一个用户，也可以list()查询出多个用户，这里显然只会有一个
    User user = query().eq("phone", phone).one();
    //判断用户是否存在
    if (user == null){
        //不存在，创建新用户并保存
        user = createUserWithPhone(phone);
    }
    //保存用户信息到session中（无论存不存在）
    session.setAttribute("user", user);
    return Result.ok();
}

private User createUserWithPhone(String phone) {
    //创建用户
    User user = new User();
    user.setPhone(phone);
    user.setNickName(USER_NICK_NAME_PREFIX + RandomUtil.randomString(10));
    //保存用户，也是mybatis-plus的功能
    save(user);
    return user;
}

现在我们可以进行测试，直接在登录注册页面填入一个数据库中不存在的phone，然后我们可以发现数据库中就新增一个新用户了，接下来就要实现登录所需要的校验了。

登录校验拦截器

对应的流程在之前已经介绍过了，根据我们做开发的一般流程，我们只需要先获取到session，然后进行逻辑判断即可。想实现这样的业务其实也是很容易的，但是这样并不是一个好方案。
这是因为我们在做登录的时候，所需要的业务是在UserController中进行的，但随着开发的完善，后续过程中可能会有OrderController或者其他的业务需要用到登录校验的流程，这就给我们的开发带来了不便。
所以我们将会设置一个SpringMVC中的拦截器，有了拦截器，用户的请求就需要先经过拦截器才能放行到各个controller中去，这样登录校验的内容就没必要再放到各个controller中进行了。
但是会产生一个新的问题，我们该如何将拦截器拦截得到的信息传到各个controller中去，同时在传递的过程中注意线程的安全问题。这个问题的解决方法是保存到ThreadLocal去。
ThreadLocal的相关方法的使用，我们可以优先封装到工具类UserHolder中：

现在我们就可以写一下拦截器的代码：

package com.hmdp.utils;

import com.hmdp.dto.UserDTO;
import org.springframework.web.servlet.HandlerInterceptor;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

public class LoginInterceptor implements HandlerInterceptor {
    //拦截器只需要重写2个方法，一个是信息进入controller之前的登录校验，一个是执行完毕后的信息销毁
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        //获取session
        HttpSession session = request.getSession();
        //获取session中的用户
        Object user = session.getAttribute("user");
        //判断用户是否存在
        if (user == null) {
            //不存在，拦截，并返回401错误码
            response.setStatus(401);
            return false;
        }
        //存在，保存用户信息到ThreadLocal
        UserHolder.saveUser((UserDTO) user);
        //放行
        return true;
    }

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

注意上面的代码不再用User类，而是UserDTO，这是因为我们要隐藏一下用户的敏感信息，我们只需要保存必要的id、name、icon信息即可。
接着在config包下配置一下拦截器就可以，记得注明一下拦截器白名单：

package com.hmdp.config;

import com.hmdp.utils.LoginInterceptor;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MvcConfig implements WebMvcConfigurer {
    //添加拦截器
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        //直接添加拦截器，并且根据业务的需要，指定一些可以放行的网址
        registry.addInterceptor(new LoginInterceptor())
                .excludePathPatterns(
                        "/user/code",
                        "/user/login",
                        "'user/me",
                        "/blog/hot",
                        "/shop/**",
                        "/shop-type/**",
                        "/upload/**",
                        "/voucher/**"
                );
    }
}

最后就是我们的controller的业务了，这个业务非常的简单，我们只需要直接从ThreadLocal中取出用户信息并返回即可：

@GetMapping("/me")
public Result me(){
    // TODO 获取当前登录的用户并返回
    UserDTO user = UserHolder.getUser();
    return Result.ok(user);
}

上面的代码还差一点，那就是我们从session中获取的得要是UserDTO而不是User了，不然没办法做校验，那么在之前的UserServiceImpl的login类中，session的保存不能再是保存User了，而是UserDTO，我们可以用BeanUtil.copyProperties方法保存我们需要的一些必要信息即可：


这个代码就算是正式调通了。

集群的session共享问题

基于session的短信登录很容易实现，但是它会有一个很大的问题——session共享问题。
session共享问题：多台Tomcat并不共享session存储空间，当请求切换到不同Tomcat服务时导致数据丢失的问题。
这是因为我们为了我们将来系统的高并发性，就需要水平拓展，形成负载均衡的集群，每个Tomcat都会有一个对应的session。当我们在某一台Tomcat上进行登录以后，第二次登录的时候，要是被负载均衡到了另一台Tomcat，就会造成没办法获得之前登录时的session，就没办法再做验证了。
这个问题听起来好像也挺容易解决，如果每台Tomcat都互相拷贝，保存相同的数据，那肯定就不至于发生如上的问题，但是这样的解决方式太浪费空间了，而且拷贝的过程还是比较费时的，如果这时候已经有访问请求，就可能会出现数据不一致的情况。
因此，我们的session信息共享的解决方案应该满足以下特点：
1、数据共享
2、内存存储
3、key-value结构
这时候我们就回到了Redis了，我们知道Redis是独立于Tomcat的，单独进行存储，且任何一台Tomcat都可以访问到Redis，因此可以实现数据共享；且Redis也满足内存存储和key-value结构。
下一节我们将讨论如何用Redis来实现短信登录，并且剖析代码的原理、调优代码。