基于Redis实现登录请求的思路,优雅!

296 阅读5分钟

基于Redis实现登录请求

开篇导读

通过学习,本文章介绍的是基于session登录以及另一种通过redis实现的登录,感谢黑马教程

1.1 、基于Session实现登录流程

Session原理:

session都有唯一的sessionId,在你访问tomcat的时候,你的浏览器会将sessionId会自动的放在cookie中,以后请求的时候会带着sessionId过来请求,因为每一个用户使用的终端都会有一个唯一的session的ID信息,因此通过Session我们可以唯一确定用户的信息。

ThreadLocal原理:

每一个进入tomcat的请求都会在tomcat线程池中分配一个独立的线程Thread。ThreadLocal开辟一个独立的内存空间来进行线程隔离,信息隔离。这个线程在访问的过程中横穿controller,service,dao各个层次,因此我们可以利用这一点和拦截器配合实现访问各个页面用户是否存在的功能。

发送验证码:

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

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

短信验证码登录、注册:

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

校验登录状态:

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

image.png

1.2、session共享问题

核心思路分析:

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

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

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

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

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

image.png

1.3 Redis代替session的业务流程

1.3.1、设计key的结构

key: String结构

value:

String结构: 存储Json字符串,会多占用存储空间

Hash结构: 每个字段独立存储,并且可以对单个字段做CRUD,内存占用少

1.3.2、设计key的具体细节

Session的key: 固定字段值(因为SessionID的不唯一性可以确定唯一用户)

redis的key: 非固定字段值,其中要求这个key具有唯一性、方便携带。因此我们采用在后台生成一个随机串token,然后让前端带来这个token来完成功能。

不建议使用phone在作为key来判断是否登录,因为这种数据太容易获取,如果采用这个来作为key判断用户登录的话,黑客可以通过获取用户手机号来骗过拦截器从而发起攻击。并且把这样的敏感数据存储到redis中并且从页面中带过来毕竟不太合适。

1.3.3、整体访问流程

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

image.png

1.4 解决状态登录刷新问题

1.4.1 初始方案思路总结:

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

image.png

1.4.2 优化方案

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

image.png

代码实现:DaiXianSenn/dj-dianping: Learning Redis and Relation Application (github.com)

我的GitHub项目实现啦,里面有详细的思路注释