怎么开个人网站,阿里云 wordpress 响应时间,电大企业网站建设论文范文,如何用网站做招聘Redis 实现分布式Session 登录 借助 Redis 对 Session 信息进行统一的存储和管理#xff0c;这样无论请求发送到哪台服务器#xff0c;服务器都会去同一个 Redis 获取相关的 Session 信息#xff0c;这样就解决了分布式系统下 Session 存储的问题。 【发送短信】校验手机号…Redis 实现分布式Session 登录 借助 Redis 对 Session 信息进行统一的存储和管理这样无论请求发送到哪台服务器服务器都会去同一个 Redis 获取相关的 Session 信息这样就解决了分布式系统下 Session 存储的问题。 【发送短信】校验手机号如果校验手机号格式正确那么就生成一个六位随机数字验证码然后把这个六位数保存到 Redis 中key 设置为业务前缀手机号value 就是 String 类型的随机数验证码设定验证码的有效时间2-3 分钟防止这个 redis 中的数据越存越多。最后将验证码返回给前端。【登录和注册】接下来用户输入手机号和验证码登录。登录时先校验手机号格式校验格式通过后之后根据前端发来的手机号手机号就是 redis 中的 key 的一部分从 redis 中获取验证码。 a. 如果验证码一致redis 保存的和用户输入的一致那么就根据手机号去数据库查找用户是否存在。 ⅰ. 如果数据库中有该用户保存用户信息到 redis便于后面逻辑的判断 比如登录判断、随时取用户信息减少对数据库的查询 随机生成一个 token使用 UUID一些业务前缀 作为登录令牌作为 redis 中的 key。存储用户信息。【putall 方法】参数: keytoken, Map(哈希表)。即以 Hash 存储到 redis存储的时候也不能一直存一直存需要设计用户信息的有效期一段时间后就清除内存。将这个 token 返回给客户端存储以后每次发送请求的时候客户端就会携带。 ⅱ. 如果数据库中没有该用户那就创建新用户补充一些用户名昵称之类的保存到用户数据库之后保存用户信息到 redis。 b. 如果验证码不一致返回失败需要重新提交验证码手机号。 相当于之后用户的登录凭证就是 redis 中的 key(token) 登录之后浏览器每次发送请求时请求头就会携带含有 token 的 Cookie。那么服务端收到之后就可以通过 token 得到 redis 中存储的 value如果得到了 value 就可以判断为登陆成功。【后续请求时校验登录状态】后续的请求都会携带 cookietoken通过 interceptor1 拦截器 1 拦截所有请求之后获取 token从而获取 redis 中的用户信息。如果成功获取到了那么就将用户信息保存到 TreadLocal 中然后刷新 token 有效期之后放行。如果没有获取到用户信息那么就直接放行交给第二个拦截器处理。 之后通过 interceptor2 拦截器 2 拦截需要登录的路径如果从 TreadLocal 中查询到用户那么就放行如果没查到那么就拦截。那些不需要登录就能访问的东西就不会被拦截了。 采用 Redis 里面的 Hash 数据结构存储 ● 对象的 String 数据结构是以 JSON 字符串的形式保存更加直观操作也更加简单但是 JSON 结构会有很多非必须的内存开销比如双引号、大括号内存占用比 Hash 更高 ● Hash 数据结构是以 Hash 表也就是 hashkey-value 的形式保存可以对单个字段进行CRUD更加灵活 为什么已经存在 redis 中了还需要存到 treadlocal 减少服务器的交互提升性能方便后续逻辑处理比如方便获取和使用用户信息Redis获取用户信息是具有侵入性的 视频软件如何维护登录状态 那就直接设计一个过期时间很久的 jwt或者返回的时候制定 cookie 过期时间这样 cookie 就会存在磁盘中关闭浏览器也不会失去 cookie。 JWT 如何设置过期时间 JWTS 工具类里面setExpiration 设置。还需设置 header 中的签名算法签名密钥。设置有效载荷 claims 等 什么时候用 JWT 什么时候用 cookie session sessioncookies是基于web的移动端用不了 cookie所以移动端一些 api 用 jwt开发 web 应用的话都可以。 Cookie Session JWT 会话跟踪技术对比 会话 在 web 开发中浏览器和服务器之间的一次连接就称之为会话。只要浏览器和服务器不断开连接那么就是属于一个会话。那么如果一个浏览器在未关闭之前请求了多次服务器那么这些请求属于同一个回话。 会话跟踪 就是一种维护浏览器状态的方法。我们后端服务器需要识别多次请求是否来自于同一个浏览器从而实现在多次请求之间共享数据。从而解决 HTTP 协议是无状态的协议的问题去辨别多次请求是否属于同一个会话从而在一次会话的多次请求之间共享数据。 Cookie 数据存储在浏览器客户端会话跟踪技术 比如第一次请求登录接口顺利通过登录校验完成之后我们就可以设置一个cookie【HttpServletResponse 的 addCookie 方法】在 cookie 当中我们可以来存储用户相关的一些数据信息。比如我可以在 cookie 当中来存储当前登录用户的用户名用户的ID 等等。 服务器端在给客户端响应数据的时候会将 cookie 响应给浏览器放在响应头 Set-Cookie 中浏览器接收到响应回来的 cookie 之后会自动的将 cookie 的值存储在浏览器本地。接下来在后续的每一次请求当中都会将浏览器本地所存储的 cookie 自动地携带到服务端放在请求头 Cookie 中。 接下来在服务端我们就可以去获取 cookie 。【HttpServletResponse 的 getCookie 方法】判断这个 cookie 中的值是否存在如果不存在这个cookie就说明客户端之前是没有访问登录接口的那后续的页面也就不能被访问只能让他访问登录界面如果存在 cookie 的值就说明客户端之前已经登录完成了。这样我们就可以基于 cookie 在同一次会话的不同请求之间来共享数据。 优点是 HTTP 中支持的技术浏览器对于 Cookie 的自动发送和接受存储都是自动的不需要我们手动操作 缺点 移动端的 APP 无法使用 cookie不是很安全因为用户可以自己禁用 cookie跨域的话不能用 cookie协议IP地址端口三者缺一就是跨域 Session 数据存储在服务器服务端会话跟踪技术 比如浏览器第一次请求服务器的时候这时候服务器会创建一个会话对象 Session可以往 Session 中存储一些数据且每一个会话对象都有一个 JsessionID。【HttpSession 的 setAttribute()方法】 接下来服务器在给浏览器相应数据的时候就会把 Session 的 ID 通过 Cookie 响应给浏览器放在响应头 Set-Cookie 中cookie 的名字是固定的 JsessionID ——代表的服务器端会话对象 Session 的 ID浏览器会自动识别这个响应头然后将 Cookie 存在浏览器本地。 接下来在后续的每一次请求当中都会将 Cookie 携带到服务端放在请求头 Cookie 中。服务器拿到 JSESSIONID 这个 Cookie 的值也就是 Session 的ID。拿到 ID 之后就会从众多的 Session 当中来找到当前请求对应的会话对象Session。【HttpSession 的 getAttribute() 方法】 这样就可以 通过 Session 会话对象在同一次会话的多次请求之间来共享数据了 优点 Session 是存储在服务端的安全 缺点 1.服务器集群不能直接用 Session。请求-负载均衡服务器-后端服务器 tomcat 集群 2.还有 Cookie 的问题 a. 不能跨域IP 地址端口号协议 b. 用户可以自己禁用 Cookie c. 移动端不能用 Cookie 令牌技术 令牌其实它就是一个用户身份的标识其实本质就是一个字符串。 在请求登录接口的时候如果登录成功我就可以生成一个令牌令牌就是用户的合法身份凭证。接下来我在响应数据的时候我就可以直接将令牌响应给前端。 前端程序接收到令牌之后就需要将这个令牌存储起来。这个存储可以存储在 cookie 当中也可以存储在其他的存储空间(比如localStorage)当中。 接下来在后续的每一次请求当中都需要将令牌携带到服务端。携带到服务端之后接下来我们就需要来校验令牌的有效性。如果令牌是有效的就说明用户已经执行了登录操作如果令牌是无效的就说明用户之前并未执行登录操作。 如果是在同一次会话的多次请求之间我们想共享数据只需要将共享的数据存储在令牌当中就可以了。 优点1. 支持 PC 端 支持移动端 2. 解决了集群环境下的认证问题因为不需要在服务器端存储数据 3. 减轻了服务器的存储压力令牌存储在客户端 缺点1. 需要自己实现令牌的生成令牌的传递令牌的校验