瑞_Redis_短信登录_Redis代替session的业务流程

本文主要是介绍瑞_Redis_短信登录_Redis代替session的业务流程，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

- 项目介绍
- 1 短信登录
- - 1.1 项目准备
  - 1.2 基于Session实现登录流程
  - 1.3 Redis代替session的业务流程
  - - 1.3.1 设计key的结构
    - 1.3.2 设计key的具体细节
    - 1.3.3 整体访问流程
    - 1.3.4 代码实现

🙊 前言：本文章为瑞_系列专栏之《Redis》的实战篇的短信登录章节的Redis代替session的业务流程小节。由于博主是从B站黑马程序员的《Redis》学习其相关知识，所以本系列专栏主要是针对该课程进行笔记总结和拓展，文中的部分原理及图解等也是来源于黑马提供的资料，特此注明。本文仅供大家交流、学习及研究使用，禁止用于商业用途，违者必究！

主机操作系统：Windows10
VMware版本： VMware Workstation 16.2.4
Linux版本：CentOS 7 64位
远程连接工具：MobaXterm_Personal_23.2
Redis版本：redis-6.2.6.tar.gz
Redis客户端：resp-2022.2.0.0
MySQL版本：8.0.29（5.7+均可）
Navicat Premium：15.0.28
JDK：1.8

相关链接：《瑞_Redis_短信登录_项目准备》
相关链接：《瑞_Redis_短信登录_基于Session实现登录流程》

瑞&3l

项目介绍

本文基于B站黑马程序员的《黑马点评》项目进行学习笔记总结和拓展，项目的相关资源和课程视频可以到B站获取。
博主提供的该项目的相关资源的某度网盘链接：https://pan.baidu.com/s/1N-yr86yTRi3LbQdAL7prEQ?pwd=q0ry

本项目具有以下功能点，本文为《短信登录》篇的Redis代替session的业务流程小节

在这里插入图片描述

短信登录
这一块我们会使用redis共享session来实现
商户查询缓存
通过本章节，我们会理解缓存击穿，缓存穿透，缓存雪崩等问题，让小伙伴的对于这些概念的理解不仅仅是停留在概念上，更是能在代码中看到对应的内容
优惠卷秒杀
通过本章节，我们可以学会Redis的计数器功能，结合Lua完成高性能的redis操作，同时学会Redis分布式锁的原理，包括Redis的三种消息队列
附近的商户
我们利用Redis的GEOHash来完成对于地理坐标的操作
UV统计
主要是使用Redis来完成统计功能
用户签到
使用Redis的BitMap数据统计功能
好友关注
基于Set集合的关注、取消关注，共同关注等等功能，这一块知识咱们之前就讲过，这次我们在项目中来使用一下
达人探店
基于List来完成点赞列表的操作，同时基于SortedSet来完成点赞的排行榜功能

由于该项目主要是为了学习Redis，所以不会设计为微服务架构，简化代码复杂度，所以采用前后端分离的单体架构

说明

手机或者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对外提供更好的服务。

在这里插入图片描述

1 短信登录

1.1 项目准备

瑞：请看《瑞_Redis_短信登录_项目准备》

1.2 基于Session实现登录流程

瑞：请看《瑞_Redis_短信登录_基于Session实现登录流程》

1.3 Redis代替session的业务流程

1.3.1 设计key的结构

首先我们要思考一下，利用redis来存储数据，那么到底使用哪种结构呢？

由于存入的数据比较简单，我们可以考虑使用String，或者是使用哈希Hash，如下图

在这里插入图片描述

（String 结构）

在这里插入图片描述

（hash 结构）

瑞：保存登录的用户信息，可以使用String结构，以JSON字符串来保存，比较直观。但是Hash结构可以将对象中的每个字段独立存储，可以针对单个字段做CRUD，并且内存占用更少。
瑞：关于Redis的数据结构，可以参考《瑞_Redis_Redis命令》

如果使用String，注意他的value，会多占用一点空间，但直观；如果使用哈希，则他的value中只会存储他数据本身。如果不是特别在意内存的情况下，其实使用String也是不错的选择。

1.3.2 设计key的具体细节

所以我们可以使用String结构，就是一个简单的key，value键值对的方式，但是关于key的处理，session他是每个用户都有自己的session，但是redis的key是共享的，咱们就不能使用code了

在设计这个key的时候，我们之前讲过需要满足两点

1️⃣ key要具有唯一性
2️⃣ key要方便携带

如果我们采用phone:手机号这个的数据来存储当然是可以的，但是如果把这样的敏感数据存储到redis中并且从页面中带过来毕竟不太合适，所以我们在后台生成一个随机串token，然后让前端带来这个token就能完成我们的整体逻辑了

1.3.3 整体访问流程

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

在这里插入图片描述

注意：后端把token返回给前端，前端以后每次请求都要携带该token。

前端逻辑分析：

1️⃣ 用 VsCode 打开提供的前端资料中的nginx-1.18.0\html\hmdp\login.html

2️⃣ 可以看到login()方法中，将后端的token保存到了浏览器缓存中

在这里插入图片描述

3️⃣ 用 VsCode 打开提供的前端资料中的nginx-1.18.0\html\hmdp\js\common.js

4️⃣ 可以看到从sessionStorage中获取到token，并定义了 request 拦截器，在每次前端发送axios请求的时候携带 authorization 的 token 请求头。后续在后端就可以获取 authorization 的 token 请求头从而拿到token实现对登录的验证（登录凭证是保存在前端浏览器的）

在这里插入图片描述