Redis高级_短信登录
内容概述
短信登录
- 这部分会使用Redis共享session来实现
但其实我在之前的瑞吉外卖的项目优化部分就做过了,用Redis替换session来存储邮箱验证码
商户查询缓存
- 这部分要理解缓存击穿,缓存穿透,缓存雪崩等问题,对于这些概念的理解不仅仅是停留在概念上,更是能在代码中看到对应的内容
优惠券秒杀
- 这部分我们可以学会Redis的计数器功能,结合Lua(之前一直想学Lua然后写饥荒mod)完成高性能的Redis操作,同时学会Redis分布式锁的原理,包括Redis的三种消息队列
附近的商户
- 利用Redis的GEOHash(新数据结构,前面没有应用场景就没介绍)来完成对于地理坐标的操作
UV统计
- 主要是使用Redis来完成统计功能
用户签到
- 使用Redis的BitMap数据统计功能
好友关注
- 基于Set集合的关注、取消关注,共同关注等等功能,这部分在上篇的练习题中出现过,这次我们在项目中来使用一下
达人探店
- 基于List来完成点赞列表的操作,同时基于SortedSet来完成点赞的排行榜功能
短信登录
导入项目
在实现功能之前,我们先来导入项目,让项目跑起来
导入SQL
黑马已经在资料中提供好了SQL文件,这里简单分析一下提供的表
表 | 说明 |
---|---|
tb_user | 用户表 |
tb_user_info | 用户详情表 |
tb_shop | 商户信息表 |
tb_shop_type | 商户类型表 |
tb_blog | 用户日记表(达人探店日记) |
tb_follow | 用户关注表 |
tb_voucher | 优惠券表 |
tb_voucher_order | 优惠券的订单表 |
有关当前模型
- 该项目采用的是前后端分离开发模式
- 手机或者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对外提供更好的服务。
导入后端项目
- 黑马已经提供好了后端项目源码压缩包,我们将其解压之后,放到自己的workspace里
- 然后修改MySQL和Reids的连接要素为自己的,随后启动项目
- 访问http://localhost:8081/shop-type/list ,如果可以看到JSON数据,则说明导入成功
导入前端工程
- 黑马已经提供好了前端项目源码压缩包,我们将其解压之后,放到自己的workSpace里
- 然后在nginx所在目录打开一个cmd窗口,输入命令,即可启动项目
1 | start nginx.exe |
- 访问http://localhost:8080/ ,打开开发者模式,可以看到页面
基于Session实现登录流程
- 发送验证码
用户在提交手机号后,会校验手机号是否合法,如果不合法,则要求用户重新输入手机号
如果手机号合法,后台此时生成对应的验证码,同时将验证码进行保存,然后再通过短信的方式将验证码发送给用户 - 短信验证码登录、注册
用户将验证码和手机号进行输入,后台从session中拿到当前验证码,然后和用户输入的验证码进行校验,如果不一致,则无法通过校验,如果一致,则后台根据手机号查询用户,如果用户不存在,则为用户创建账号信息,保存到数据库,无论是否存在,都会将用户信息保存到session中,方便后续获得当前登录信息 - 校验登录状态
用户在请求的时候,会从cookie中携带JsessionId到后台,后台通过JsessionId从session中拿到用户信息,如果没有session信息,则进行拦截,如果有session信息,则将用户信息保存到threadLocal中,并放行
实现发送短信验证码功能
- 输入手机号,点击发送验证码按钮,查看发送的请求
请求网址: http://localhost:8080/api/user/code?phone=15832165478
请求方法: POST
- 看样子是调用UserController中的code方法,携带参数是phone,看黑马提供的源码也证实了我的猜想
1 | /** |
- 但是黑马这里并不会真的使用短信服务发送验证码,只是随机生成了一个验证码,那我这里为了后期项目能真的部署上线,还是打算用邮箱验证
- 由于黑马这里貌似没有设置前端的手机号正则判断,所以我们只需要去数据库中修改phone的字段类型,将varchar(11)改为varchar(100)
- 导入邮箱验证需要的maven坐标
1 | <!-- https://mvnrepository.com/artifact/javax.activation/activation --> |
- 然后编写一个工具类,用于发送邮件验证码
1 | import java.util.Arrays; |
修改sendCode方法,逻辑如下
- 验证手机号/邮箱格式
- 不正确则返回错误信息
正确则发送验证码
1 | /** |
- 然后输入邮箱,发送验证码,看看能否接收到验证码
- 测试没有问题之后,我们继续来编写登录功能,点击登录按钮,查看发送的请求
请求网址: http://localhost:8080/api/user/login
请求方法: POST
- 看样子是UserController中的login方法,携带的参数也就是我们的邮箱和验证码
1 | {phone: "1586385296@qq.com", code: "iMPKc"} |
- 黑马提供的代码如下,看样子是把邮箱和验证码封装到了LoginFormDto中
- login
1 | /** |
- LoginFormDTO
1 |
|
修改login方法,逻辑如下
- 校验手机号/邮箱
- 不正确则返回错误信息
正确则继续校验验证码
- 不一致则报错
一致则先根据手机号/邮箱查询用户
- 用户不存在则创建
存在则继续执行程序
- 保存用户信息到session中
login
1 | /** |
- createUserWithPhone
1 | private User createUserWithPhone(String phone) { |
实现登录拦截功能
- 这部分需要用到拦截器的知识,我在前面的SSM整合篇做过详细介绍
SSM整合https://cyborg2077.github.io/2022/09/10/SSMIntegration/
- 创建一个LoginInterceptor类,实现HandlerInterceptor接口,重写其中的两个方法,前置拦截器和完成处理方法,前置拦截器主要用于我们登陆之前的权限校验,完成处理方法是用于处理登录后的信息,避免内存泄露
- LoginInterceptor
1 | public class LoginInterceptor implements HandlerInterceptor { |
- UserHolder
这是黑马已经提供好了的一个工具类
1 | public class UserHolder { |
- MvcConfig
1 |
|
- 顺便再写一下me方法
1 |
|
隐藏用户敏感信息
- 我们通过浏览器观察到此时用户的全部信息都在,这样极为不靠谱,所以我们应当在返回用户信息之前,将用户的敏感信息进行隐藏,采用的核心思路就是书写一个UserDto对象,这个UserDto对象就没有敏感信息了,我们在返回前,将有用户敏感信息的User对象转化成没有敏感信息的UserDto对象,那么就能够避免这个尴尬的问题了
1 | { |
- UserDto类如下,将User对象中的属性拷贝给UserDto,就可以避免暴露用户的隐藏信息
1 |
|
- 修改UserHolder,将其User类型都换为UserDto
1 | public class UserHolder { |
- 修改login方法_DIFF
1 | @PostMapping("/login") |
- 修改拦截器
1 | @Override |
- 重启服务器,登录后查看此时的用户信息,敏感信息已经不存在了
1 | { |
session共享问题
- 每个tomcat中都有一份属于自己的session,假设用户第一次访问第一台tomcat,并且把自己的信息存放到第一台服务器的session中,但是第二次这个用户访问到了第二台tomcat,那么在第二台服务器上,肯定没有第一台服务器存放的session,所以此时 整个登录拦截功能就会出现问题,我们能如何解决这个问题呢?早期的方案是session拷贝,就是说虽然每个tomcat上都有不同的session,但是每当任意一台服务器的session修改时,都会同步给其他的Tomcat服务器的session,这样的话,就可以实现session的共享了
- 但是这种方案具有两个大问题
- 每台服务器中都有完整的一份session数据,服务器压力过大。
- session拷贝数据时,可能会出现延迟
- 所以我们后面都是基于Redis来完成,我们把session换成Redis,Redis数据本身就是共享的,就可以避免session共享的问题了
Redis替代session的业务流程
设计key结构
首先我们来思考一下该用什么数据结构来存储数据
由于存入的数据比较简单,我们可以使用String或者Hash
- 如果使用String,以JSON字符串来保存数据,会额外占用部分空间
如果使用Hash,则它的value中只会存储数据本身
如果不是特别在意内存,直接使用String就好了
设计key的具体细节
- 我们这里就采用的是简单的K-V键值对方式
- 但是对于key的处理,不能像session一样用phone或code来当做key
- 因为Redis的key是共享的,code可能会重复,phone这种敏感字段也不适合存储到Redis中
- 在设计key的时候,我们需要满足两点
- key要有唯一性
- key要方便携带
- 所以我们在后台随机生成一个token,然后让前端带着这个token就能完成我们的业务逻辑了
整体访问流程
当注册完成后,用户去登录,然后校验用户提交的手机号/邮箱和验证码是否一致
- 如果一致,则根据手机号查询用户信息,不存在则新建,最后将用户数据保存到Redis,并生成一个token作为Redis的key
当我们校验用户是否登录时,回去携带着token进行访问,从Redis中获取token对应的value,判断是否存在这个数据
- 如果不存在,则拦截
如果存在,则将其用户信息(userDto)保存到threadLocal中,并放行
基于Redis实现短信登录
- 由于前面已经分析过业务逻辑了,所以这里我们直接开始写代码,在此之前我们要在UserController中注入StringRedisTemplate
1 |
|
- 修改sendCode方法
- 修改sendCode方法
这里的key使用用login:code:email的形式,并设置有效期2分钟,我们也可以定义一个常量类来替换这里的login:code:和2,让代码显得更专业一点
1 | @PostMapping("/code") |
- RedisConstants
定义的常量类
1 | public class RedisConstants { |
- 修改login方法
1 | @PostMapping("/login") |
- 修改后代码
1 |
|
解决状态登录刷新问题
初始方案
- 我们可以通过拦截器拦截到的请求,来证明用户是否在操作,如果用户没有任何操作30分钟,则token会消失,用户需要重新登录
- 通过查看请求,我们发现我们存的token在请求头里,那么我们就在拦截器里来刷新token的存活时间
authorization: 6867061d-a8d0-4e60-b92f-97f7d698a1ca
- 修改我们的登陆拦截器LoginInterceptor类
1 |
|
- 在这个方案中,他确实可以使用对应路径的拦截,同时刷新登录token令牌的存活时间,但是现在这个拦截器他只是拦截需要被拦截的路径,假设当前用户访问了一些不需要拦截的路径,那么这个拦截器就不会生效,所以此时令牌刷新的动作实际上就不会执行,所以这个方案他是存在问题的
优化方案
- 既然之前的拦截器无法对不需要拦截的路径生效,那么我们可以添加一个拦截器,在第一个拦截器中拦截所有的路径,把第二个拦截器做的事情放入到第一个拦截器中,同时刷新令牌,因为第一个拦截器有了threadLocal的数据,所以此时第二个拦截器只需要判断拦截器中的user对象是否存在即可,完成整体刷新功能。
- 新建一个RefreshTokenInterceptor类,其业务逻辑与之前的LoginInterceptor类似,就算遇到用户未登录,也继续放行,交给LoginInterceptor处理
由于这个对象是我们手动在WebConfig里创建的,所以这里不能用@AutoWired自动装配,只能声明一个私有的,到了WebConfig里再自动装配
1 | public class RefreshTokenInterceptor implements HandlerInterceptor { |
- 修改我们之前的LoginInterceptor类,只需要判断用户是否存在,不存在,则拦截,存在则放行
1 | public class LoginInterceptor implements HandlerInterceptor { |
- 修改WebConfig配置类,拦截器的执行顺序可以由order来指定,如果未设置拦截路径,则默认是拦截所有路径
1 |
|
那么至此,大功告成,我们重启服务器,登录,然后去Redis的图形化界面查看token的ttl,如果每次切换界面之后,ttl都会重置,那么说明我们的代码没有问题