一、基于session实现登录功能
-
第一步:发送验证码:
- 用户在提交手机号后,会校验手机号是否合法:
- 如果不合法,则要求用户重新输入手机号
- 如果手机号合法,后台此时生成对应的验证码,同时将验证码进行保存(存到session里面),然后再通过短信的方式将验证码发送给用户
- 用户在提交手机号后,会校验手机号是否合法:
-
第二步:短信验证码登录、注册:
- 用户输入刚刚获取到的验证码,而后台则从session中拿到当前验证码,
然后和用户输入的验证码进行校验
:- 如果不一致,则无法通过校验(提示验证码错误)
- 如果一致,则后台根据手机号查询用户:
- 如果用户不存在,则为用户创建账号信息,保存到数据库,再将用户信息保存到session中
- 如果存在,则直接存入到session中取。
- 无论是否存在,都会将用户信息(这个用户信息可以创建个UserDTO对象,把想要暴露的信息存储到session中去,这样就可以减少数据暴露的风险)保存到session中,方便后续获得当前登录信息。
- 用户输入刚刚获取到的验证码,而后台则从session中拿到当前验证码,
-
第三步:校验登录状态(登录时的逻辑):
- 用户在请求登录的时候,会
从cookie中携带者JsessionId到后台
,后台通过JsessionId从session中拿到用户信息- 如果没有session信息,则进行拦截,无法进行登录。
- 如果有session信息,则
将用户信息保存到threadLocal中
,并且放行。
- 用户在请求登录的时候,会
-
使用拦截器:当每个业务都需要进行用户信息的验证时,不可能每个业务都写一次登录校验的逻辑,这就需要使用到拦截器了(拦截器是在所有的业务执行之前执行的)。我们把这个登录校验的逻辑写到拦截器里面去,这样每次用户无论访问哪个业务都需要经过拦截器,然后让拦截器判断是否放行该用户访问业务。
-
tomcat运行原理:
-
当用户发起请求时,会访问我们向tomcat注册的端口:
-
任何程序想要运行,都需要有一个线程对当前端口号进行监听,tomcat也不例外。
-
当监听线程知道用户想要和tomcat进行连接时,那会由监听线程创建socket连接。
- socket都是
成对
出现的,用户通过socket互相传递数据,当tomcat端的socket接收到数据后,此时监听线程会从tomcat的线程池中取出一个线程执行用户请求。
- socket都是
-
当我们的服务部署到tomcat后,线程会找到用户想要访问的工程,然后用这个线程转发到工程中的controller,service,dao中,并且访问对应的DB,在用户执行完请求后,再统一返回,再找到tomcat端的socket,再将数据写回到用户端的socket,完成请求和响应
-
结论:
每个用户其实对应都是去找tomcat线程池中的一个线程来完成工作的, 使用完成后再进行回收,既然每个请求都是独立的,所以在每个用户去访问我们的工程时,我们可以使用threadlocal来做到线程隔离,每个线程操作自己的一份数据
(Threadlocal的基本使用)- 在threadLocal中,无论是它的put方法和他的get方法, 都是先从获得当前用户的线程,然后从线程中取出线程的成员变量map,只要线程不一样,map就不一样,所以可以通过这种方式来做到线程隔离。
二、集群的session共享问题(使用redis代替)
- session共享问题:其实就是多台tomcat服务器并不共享session存储空间(每个tomcat有自己的session),当请求切换到不同的tomcat服务时导致数据丢失的问题。
思路分析:
- 每个tomcat中都有一份属于自己的session,假设用户
第一次访问
第一台tomcat,并且把自己的信息存放到第一台
服务器的session中; - 但是第二次这个用户访问到了第二台tomcat,那么在第二台服务器上,肯定没有第一台服务器存放的session,所以此时 整个登录拦截功能就会出现问题,我们能如何解决这个问题呢?
- 早期的方案是
session拷贝
,就是说虽然每个tomcat上都有不同的session,但是每当任意一台服务器的session修改时,都会同步给其他的Tomcat服务器的session,这样的话,就可以实现session的共享了,但是这种方案具有两个大问题:- 1、每台服务器中都有完整的一份session数据,·服务器压力过大·。
- 2、session拷贝数据时,可能会出现
延迟
。
- 早期的方案是
解决方法:
- 基于
redis
来完成,我们把session换成redis,redis数据本身就是共享的,就可以避免session共享的问题了。
第一步:设计redis的value的结构
- 利用redis来存储数据,那么到底使用哪种结构呢?
- 如果存入的数据比较简单,我们可以考虑使用
String
,或者是使用哈希
。- 当存入的数据是一个对象时,value如果使用String结构时,会把java对象序列化成一个json字符串然后存储。(使用string结构时,会有一些额外的数据存储,比如json的格式等等,而且每次修改都要修改整个字符串)
- 当存入的数据是一个对象时,value如果使用哈希,则它的value中只会存储数据本身,修改可以直接修改单个字段。
- 如果不是特别在意内存,其实使用String就可以啦。
- 如果存入的数据比较简单,我们可以考虑使用
第二步:redis的key的设计
- 1、key要具有唯一性
- 2、key要方便携带
第三步:设置redis的key的存活时间
- 就好比你使用百度等其它的软件时,你每次登录进去之后,在一段时间之内,退出来再进去都不需要再重新进行登录(只要不是退出登录),过了特定的时间之后,就需要重新登录了。(原因就可以理解为存储你登录信息的数据的key过期了,存储在redis的登录数据没了)
- 具体设计:只要用户还在操作,无论在访问哪个服务都需要
重新刷新key的存活时间
,只有当用户不再操作的时候,才会计算key的存活时间,直到时间过去之后才会销毁key。
整体访问流程
- 用户去登录时,会去校验用户提交的手机号和验证码,是否一致,如果一致,则根据手机号查询用户信息,并将用户数据保存到redis,并且生成token作为redis的key。
- 如果用户不存在则新建一个用户,然后将新建用户的数据保存到数据库中,然后再保存到redis,并且生成token作为redis的key,
- 当我们校验用户是否登录时,会去携带着token进行访问,从redis中取出token对应的value,判断是否存在这个数据
- 如果不存在这个数据则拦截登录
- 如果存在则将其保存到threadLocal中,并且放行。