第三章 通行证服务

短信登陆：第三方短信收发，借助阿里云短信服务
短信验证码：限制用户60s内发起一次短信
分布式会话：用户登陆后，Redis 保存用户会话的 token，使用 Redis 管理
用户信息完善：涉及用户头像，则用到文件上传系统

流程

@Api(value = "用户注册登录", tags = {"用户注册登录的controller"})
@RequestMapping("passport")
public interface PassportControllerApi {
    @ApiOperation(value = "获得短信验证码", notes = "获得短信验证码", httpMethod = "GET")
    @GetMapping("/getSMSCode")
    public GraceJSONResult getSMSCode(@RequestParam String mobile, HttpServletRequest request);
    @ApiOperation(value = "一键注册登录接口", notes = "一键注册登录接口", httpMethod = "POST")
    @PostMapping("/doLogin")
    public GraceJSONResult doLogin(@RequestBody @Valid RegistLoginBO registLoginBO,
                                   BindingResult result,
                                   HttpServletRequest request,
                                   HttpServletResponse response);
    @ApiOperation(value = "用户退出登录", notes = "用户退出登录", httpMethod = "POST")
    @PostMapping("/logout")
    public GraceJSONResult logout(@RequestParam String userId,
                                   HttpServletRequest request,
                                   HttpServletResponse response);
}

一、发送短信验证码

短信服务

（无需配置阿里云业务，发送验证码后直接在 redis 中查看即可）

阿里云短信功能，阿里云服务

AliyunResource 资源类，获取密钥，配置文件中配置
资源里注入容器

发送短信的SMSUtils类

完善短信发送接口：Redis 中存储 验证码 和 用户IP

验证码发出会会进行保存，单体项目用session保存也行；但是分布式项目中，还是用 Redis 保存.

在 getSMSCode 方法中补充形参
moblile为手机号，request获取 IP 便于判断是否发送 60 秒

public GraceJSONResult getSMSCode(String mobile, HttpServletRequest request) {
    // 获得用户ip
    String userIp = IPUtil.getRequestIp(request);
    // 根据用户的ip进行限制，限制用户在60秒内只能获得一次验证码
    redis.setnx60s(MOBILE_SMSCODE + ":" + userIp, userIp);
    // 生成随机验证码并且发送短信
    String random = (int)((Math.random() * 9 + 1) * 100000) + "";
//        smsUtils.sendSMS(MyInfo.getMobile(), random);
    // 把验证码存入redis，用于后续进行验证
    redis.set(MOBILE_SMSCODE + ":" + mobile, random, 30 * 60);
    return GraceJSONResult.ok();
}

（2）保存发送验证码的用户信息

① 导入 IP 工具类

    因为有了 request ，就可以根据用户 IP 限制60s内用户只能发送一次短信！
    ip 需要从 request 中获取，老师事先加入了一个 IPutil 在 common 工程中，用于获取用户 ip，直接使用即可。

② 注入redis操作对象，并建立baseController，提取公共代码

    需要用到 Redis ，限制用户60s内只能获取一次验证码。把 redisoperator 注入进来，调用 setnx60x 方法（老师自己加的）（key不存在就会设置，超过60s就会消失）.
    redis 里面存的信息有两部分：smscode（key值） + ip。其中key不会写死，会写在公共的地方！因此把 key 提取，写在 api 工程中.
    api 中，定义 baseController 这个 class 。方法中，注入 redis 操作类，声明一个 key 常量.

③ 继续完善 passportcontroller

    回到 passportcontroller ，继承 baseController ，redis 就可以去掉了，redis 的60s方法中的形参改一改：
    这样，通过 "**常量 + IP**" 的方式，就组合成了 key ，只要这个 key 在，就不能再次发送！
    至于验证码，随便写一个：ip 即可<br />==>  ？？？？？是不是还没有设置，不足60s时不能再次发送的警告？？？

（3）生成随机验证码，并发送短信

然后就来设置验证码信息

    验证码就在一开始那两节留下的代码上改就行
    验证码随机数就行，如下：（6位即可）

（4）验证码存入redis，用于后续验证

短信存在 redis 中（？？？啥时候存的？？？）==> 这应该就是个业务逻辑.

    注意！图中37行，老师这里 sendSMS 中，我们自己形参得用方法形参 mobile 而非老师写的 myinfo.getMobile ，因为老师要隐藏自己手机号才这么写的，我们自己就和其他地方一样，用方法传进来的moblie ==> 这个mobile其实就是前端页面输入手机号以后传进来的.
    40行set时，加上时间设置，验证码有效时间为30min.

拦截并限制 60s 用户短信发送

1 问题分析：“60s内不可重复发送”的问题未解决

前端发送的验证码，按理说60s内不能重复发送。
但是，老师演示了以下，如果刷新了前端页面，发送按钮的也会被刷新，此时点击发送，仍然可以对同一用户发送信息，同时redis中的验证码会发生变更，这就与我们的初衷违背。

    之前的代码，实现的只是，用户信息、验证码这些，到时间了自动消失。<br /> 本节课要写的，就是规定时间内，再次发送，会对请求进行拦截！<br />    如下图，60s这个方法，补充判断，只要 key 存在，调用这个接口时，就进行拦截！

2 编写验证码拦截器类
如果要在方法之前进行拦截，那么就需要晚上preHandle这个方法。其他两个不用管

首先，我们得获得用户的 IP ，然后通过 Redis 获得key.<br />        通过 keyExist 方法判断 key 是否存在.  不存在，放行即可.<br />        如果存在，让前端做一个抛出，返回一个错误的 json，前端接收到后提示发送频率太高了.<br />        所以这里需要构建 json。但是先用 sout 来过渡以下，下节课讲“自定义异常——统一异常处理”.

3 配置拦截器
interceptor写好以后，还需要进行配置，放到容器里面才能正常运作

    在 api 工程中 config 包下加配置类

5 自定义异常，返回错误信息：60s内不可重复发送验证码

    紧接上节课，完善要返回给前端的**报错 JSON 信息**！

==> 只要拦截到自己写的自定义异常，捕获以后，就会以 JSON 字符串的形式，抛给前端。不管是浏览器端，还是手机端，都可以拿到这个异常信息，然后再提示用户

视频 3-7 跨域问题？？？和cookie有关吗？

二、一键注册登录

API中定义接口名称：dologin.（还是那个passportAPI）。

    **涉及到表单，注解为 PostMapping**（查询的话就是getMapping）；注意，**ApiOperation 中的 httpMethod 是 POST** 而非 GET！

最终代码：doLogin

UUIDL：统一XX码，去了解下

    @Override
    public GraceJSONResult doLogin(@Valid RegistLoginBO registLoginBO,
                                   BindingResult result,
                                   HttpServletRequest request,
                                   HttpServletResponse response) {
        // 0.判断BindingResult中是否保存了错误的验证信息，如果有，则需要返回
        if (result.hasErrors()) {
            Map<String, String> map = getErrors(result);
            return GraceJSONResult.errorMap(map);
        }
        String mobile = registLoginBO.getMobile();
        String smsCode = registLoginBO.getSmsCode();
        // 1. 校验验证码是否匹配
        String redisSMSCode = redis.get(MOBILE_SMSCODE + ":" + mobile);
        if (StringUtils.isBlank(redisSMSCode) || !redisSMSCode.equalsIgnoreCase(smsCode)) {
            return GraceJSONResult.errorCustom(ResponseStatusEnum.SMS_CODE_ERROR);
        }
        // 2. 查询数据库，判断该用户注册
        AppUser user = userService.queryMobileIsExist(mobile);
        if (user != null && user.getActiveStatus() == UserStatus.FROZEN.type) {
            // 如果用户不为空，并且状态为冻结，则直接抛出异常，禁止登录
            return GraceJSONResult.errorCustom(ResponseStatusEnum.USER_FROZEN);
        } else if (user == null) {
            // 如果用户没有注册过，则为null，需要注册信息入库
            user = userService.createUser(mobile);
        }
        // 3. 保存用户分布式会话的相关操作
        int userActiveStatus = user.getActiveStatus();
        if (userActiveStatus != UserStatus.FROZEN.type) {
            // 保存token到redis
            String uToken = UUID.randomUUID().toString();
            redis.set(REDIS_USER_TOKEN + ":" + user.getId(), uToken);
            redis.set(REDIS_USER_INFO + ":" + user.getId(), JsonUtils.objectToJson(user));
            // 保存用户id和token到cookie中
            setCookie(request, response, "utoken", uToken, COOKIE_MONTH);
            setCookie(request, response, "uid", user.getId(), COOKIE_MONTH);
        }
        // 4. 用户登录或注册成功以后，需要删除redis中的短信验证码，验证码只能使用一次，用过后则作废
        redis.del(MOBILE_SMSCODE + ":" + mobile);
        // 5. 返回用户状态
        return GraceJSONResult.ok(userActiveStatus);
    }

0 验证BO信息

创建 BO 类

方法形参，**<u>如果要接收数据，一般都命名为“BO”，表示从业务层接收数据</u>**。**本质就是一个“entity”对象**<br />方法形参，**<u>如果要接收数据，一般都命名为“BO”，表示从业务层接收数据</u>**。<br />**本质就是一个“entity”对象**：**<u>主要接收：手机号 和  验证码</u>**。生成get/set方法，toString等.<br />因为是从前端过来的，可以**对BO类其属性进行一个验证**：两个属性加@notnull (message=...) 检测是否为空，如果为空，返回message中的信息
    ==>后续**更正 @notnull 为 @notblank**。notnull只能看这个信息是不是null；如果这个信息是""这种blank类型，notnull不会报错！

blank 的话 null 和 blank 会一起检测。

当然，BO 需要加上 @Valid注解 表示内部需要验证；Bo 还要加上 @RequestBody 来表明：该形参和前端传过来的 JSON 串是匹配的（这个很重要，不加的话，里面数据获得不了）；

（1） 补充处理BO验证错误信息的方法：getErrors

为了专门处理 BO 中的错误信息（因为有两类错误信息：手机号 / 短信验证码 不能为空），专门拿到 result 形参去重写一个方法。

    我们之前在Bo类中，声明了 手机号 和 验证码 的属性，以及 notnull 中的错误信息 —> 我们就把 属性 和 message 匹配成一组 map 存储.

dologin方法 初步

<1> 判断 BindingResult 是否保存错误的验证信息

    第一部分就是通过 result 和我们刚才重写的方法拿到了可能的手机号/验证码不存在的 错误信息。如果有，则直接return。
    有错的话返回即可.

<2> 获取前端信息，并“ 校验验证码是否匹配 ”

① 操作：从BO里获得 手机号 + 验证码

    拿到了就可以校验了

②

    对于验证码，我们要两个：前端传过来的 + redis中储存的
    ∴需要redis。    但是redis我们已经创建过了：当前controller继承的baseController中创建了redis操作类

操作：用redis获得验证码

③ 拿到以后：先看看是否超时/失效了

然后再看匹不匹配

不匹配时，返回对应状态码枚举类sms_code_error

④ 代码如下：

1 Service层方法，一键注册登陆时：查询用户 + （用户不存在时）新用户注册

本节进入一键注册登录的流程！包含了两个数据库方面的操作，根据 mobile 查找数据库：
            ①如果用户存在，可以**直接登陆**；
            ②没有，则在数据库中**创建用户**；

看表

根据数据库中信息决定接口中用什么方法

查看“用户表”（激活状态这一项比较多，后面看看）

接口

实现查询用户

①

    对于查询的话，就要使用mapper了，第二章最后整合 mybatis 时这些我们已经弄好了（忘了回去复习）.
    注入 appuserMapper ；（注意，如果appUserMapper下有红色波浪线，直接运行可能是可以的，不报错，只不过IDEA编译器有个检索的过程。  如果想要去掉波浪线，可以去原mapper类那里加一个数据层@repository的注解）<br />②
    然后继续操作.    实现类中还是先把 mapper 注入.    查询方法中，Example是针对 appuser 的一个“查询实例”（这个是自己写的还是框架提供的可以直接用？？？==>mybatis提供的吧）

③ Criteria可以封装“查询条件”。

    封装“判断条件”：其andEqualTo方法中，左边那个是Appuser中的形参，右边那个moblile是当前查询方法传回的形参
    这个“判断条件”就被包含在example对象中了.

④

    调用 select 方法，传入 example ，其中就包含了刚才写的 “判断条件” 。返回一个 Appuser（这个和我们创建 example 时传入的类对象是一致的），不存在时，appuser为null。

⑤ 写好后代码如下：

实现创建用户（个人信息初始化）

用户对象包含一些默认信息需要我们去构建. user 先 new 出来.

① ID

分布式环境中，业务量继续增多过程中，考虑“分库分表”。此时，自增主键的效率就非常差了，此时我们选择：“全局ID”；
需要第三方组件，如下图：idworker 这个包，里面有个 Sid ，就用这个.（放在common工程中）

因此我们把sid注入到实现类中

此时调用sid，如下：通过 nextShort 拿到全局 ID，然后 setId 即可（可以看看图中老师的注释）

②mobile

③昵称：我们这里就用手机号作为昵称

    但是呢，最好还是进行脱敏，别让别人直接拿到你的手机号.
    调用第三方工具，老师 已经导入utils包下，如下：

④用户头像：setFace

    头像老师这里提供了3个，放在了他自己的服务器上。我们就按它的代码即可。

⑤生日

    为了能把字符串转换成date类型：需要用到第三方工具：如图，已经添加到utils包中了
    （有自己的工具类也可以用自己的）<br />⑥性别
    为了提高通用性，用枚举类更好。
    老师已经把项目可能用到的枚举搞了一些进来了，如图：其中sex就是我们这里要用的.

⑦激活状态

    同⑥，也是有对应的枚举，如下：使用未激活的状态.

3 一键注册登录 方法中，判断用户是否注册

2 设置会话与 cookie 信息

一、保存用户分布式会话的操作

    上节课两个操作都是在service层.    本节完善这一部分.
    用户注册和登陆以后，会产生相应的会话。用户会话早期都是直接用 request 中的 session ；现如今使用**分布式会话，会话信息存入redis，任何节点都能获取；将 cookie 和后端的 token 结合起来**。

到这一步，用户要么注册，要么登陆.

（1）保存token到redis中（token是什么）
用user获取激活状态（只要和业务相关，就要进行“激活状态判断”，这是基本的）

    **用户的会话一般都是用字符串形式的token**（？？？），这里使用随机的UUID（？？？？）。<br />        然后保存信息到 redis 。redis 这里set时需要一个key，在前面声明：

（2）保存用户id和token到cookie中1——补充setCookie方法
（？？？？？？其实没理解，咋拿到cookie的，也没调用request啊？）

① 接口方法补充形参

    同时，因为前后端分离，token也应该保存在前端 .
    回到 PassportControllerApi 接口，doLogin 方法补充形参：
response 和 request 都是获取 cookie 所需要的

④ 抽离另一种需求的 setCookie 方法 & 优化：编码不是utf-8时，直接设置即可（比上一个方法少了一个encode而已，此时异常也不需要了）
[注意]这里最后还补充了一个“把cookie存入reponse”的代码！！！

（3）保存用户id和token到cookie中2——完善Controller类中方法

超时时间 maxAge 在 BaseController 中统一设置：

（这里设置1个月）

3 用户注册或者登陆以后，需要删除 redis 中的短信验证码，验证码只能使用一次，用过后删除

4 返回用户状态

这里需要return的是user的状态而非user，

三、用户账户信息完善

查询用户“详细”信息：getAccountInfo

代码

    @Override
    public GraceJSONResult getAccountInfo(String userId) {
        // 0. 判断参数不能为空
        if (StringUtils.isBlank(userId)) {
            return GraceJSONResult.errorCustom(ResponseStatusEnum.UN_LOGIN);
        }
        // 1. 根据userId查询用户的信息
        AppUser user = getUser(userId);
        // 2. 返回用户信息（VO类）
        UserAccountInfoVO accountInfoVO = new UserAccountInfoVO();
        BeanUtils.copyProperties(user, accountInfoVO);
        return GraceJSONResult.ok(accountInfoVO);
    }

分析

    用户登陆注册完成后，需要用户信息进行更新。<br />        当时就跳转到了这里：需要操作的就在这！<br />![](http://img.mukewang.com/szimg/625a3b580001c23b19201080-500-284.jpg#crop=0&crop=0&crop=1&crop=1&id=JplT9&originHeight=281&originWidth=500&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)

更新前，当前页面中有一部分信息没有展示
所以先把用户信息展示出来，在页面中显示，然后就可以修改或提交.

通信证 / 用户注册登陆 的代码我们都写在了 PassportController 中。
用户信息，我们就创建一个新的Controller：【UserControllerApi】；
（位置和PassportController的接口一样）

实现 getAccoutnInfo 方法，根据 id 查用户信息，创建 VO 类

位置和 p..c.. 一样

判断参数不为空

    id为空时，抛出“未登陆”的错误

根据 id 查用户信息

【需要service】==>补充user方法
之前有个userService，那么就在这里补充：

Service层 实现 getUser 方法， 后面会公用，所以将其抽取出来

新建Vo类

user是持久层的数据，并不是所有信息都需要.
一般是用什么，加载什么==>一般会构建一个视图层对象：VO类，让视图层渲染与加载.
∴ user对象一般是不会直接抛出的（假如user有密码，不也直接抛出了嘛）
因此，我们需要先搞一个Vo类！
先搞个vo包，位置：

复制一个AppUser类，直接在这个基础上改！
保留以后的属性如下：
（激活状态，创建时间什么的就不要了）
然后什么get/set/toString就自己生成
（shfit + f6 快速修改文件名）

BeanUtils 工具类：拷贝 AppUser 信息到 Vo 类中

通过一个 BeanUtils 工具类进行属性拷贝！属性名匹配就能拷贝！！！<br />    （ BeanUtils 属于 package org.springframework.beans; 这个类不是我们自己导入的，靠依赖导入）<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655822882897-5517b007-34f8-41fd-a830-06055aa9fdc0.jpeg#clientId=u1c0d6287-7539-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u8c9fcfef&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u7290a943-e400-4ce4-9b98-636d0f679e0&title=)

更新用户信息：updateUserInfo

更新用户信息代码

（后面 缓存双写 时，会优化 service 层的 updateUserInfo）

public GraceJSONResult updateUserInfo(
            @Valid UpdateUserInfoBO updateUserInfoBO,
            BindingResult result) {
        // 0. 校验BO
        if (result.hasErrors()) {
            Map<String, String> map = getErrors(result);
            return GraceJSONResult.errorMap(map);
        }
        // 1. 执行更新操作
        userService.updateUserInfo(updateUserInfoBO);    //后面要更新补充redis的逻辑
        return GraceJSONResult.ok();
    }

提交信息前，信息校验（同登陆时的BO验证）

我们现在需要填写如下个人信息，并且提交。
登陆前需要对 手机号 和 验证码判空，这里提交信息前的信息校验也是同理！就是看看提交的信息是否合理！！
信息还是表单类的信息.
我们首先要做的就是【通过 VO 进行信息的验证】.

编写BO（包含判断信息合法性的注解）

涉及到了BO，我们专门去写一份。**Model 项目的 BO 包中**.<br />    代码是准备好的，直接复制：@ length是用来判断长度的；@Email是用来判断右键类型格式的； 性别中 max 和 min 帮助限定可选值；日期中JSONFormate是用来格式化的（不太懂）；

set 和 get 还是需要自己生成
（这里 JSONFormate 和 Length 都没有，都是我自己根据报的错引入的依赖，不知道对不对啊！！！）

updateUserInfo 方法：校验 BO + 执行更新操作

来到 UserController，先继承一下baseController
（1）校验 BO，写法和之前的一样
（2）执行更新操作

提交信息，激活用户，信息入库

本节课开始【完善更新操作】（如下图中，还没写呢）

———————————————————————————————————-

1 调用 Service 传递BO信息

（1）UserService 中补充方法

（最下面）
业务逻辑：用户信息完善后，就是一个激活的状态！

（2）Service实现类中实现方法

拿到主键，根据主键利用持久层对象拷贝数据（从BO搞到user对象中）；
依然使用 BeanUtils 工具类；
BO中没有的，我们手动追加；
最后，就可以执行更新.
主键更新方法有两个，primarykey 这个方法会把没传值的数据覆盖（比如创建时间啥的，传入的数据没有，那么就是null，但是数据库中不是null，如果用这个方法，会覆盖）；所以选择 selective 的方法，根据现有的数据覆盖

入库操作会返回一个结果，拿到这个结果，判断一下，看一下更新操作是否合法： 如果不合法，我们直接处理错误，吗，没有返回给controller让controller去处理，相当于一种解耦.

（3）回到controller，调用刚才写好的方法

查询用户“基本”信息：getUserInfo（只显示关键信息，后面用）

目前也已经更新了用户的信息到数据库，并已经做了激活.<br />按理说，用户激活后，左侧菜单可以点击：但是因为用于【基本信息接口】我们都还没有写，所以还点不了；<br />我们之前处理的只是“账户信息”：在 （§ 2.2 注册登录 五）中，我们已经完成了用户详细信息的查询.<br />（这块逻辑其实可以再听听）

代码

getUser 在下一部分需要通过 redis 优化！

@Override
    public GraceJSONResult getUserInfo(String userId) {
        // 0. 判断参数不能为空
        if (StringUtils.isBlank(userId)) {
            return GraceJSONResult.errorCustom(ResponseStatusEnum.UN_LOGIN);
        }
        // 1. 根据userId查询用户的信息
        AppUser user = getUser(userId);
        // 2. 返回用户信息
        AppUserVO userVO = new AppUserVO();
        BeanUtils.copyProperties(user, userVO);
        // 3. 查询redis中用户的关注数和粉丝数，放入userVO到前端渲染
        userVO.setMyFansCounts(getCountsFromRedis(REDIS_WRITER_FANS_COUNTS + ":" + userId));
        userVO.setMyFollowCounts(getCountsFromRedis(REDIS_MY_FOLLOW_COUNTS + ":" + userId));
        return GraceJSONResult.ok(userVO);
    }

追加 “基本信息VO类”，只显示部分关键信息

    保留属性如下：<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655824924355-9d459204-5da8-40f3-8fbc-3742c8e800dc.jpeg#clientId=u1c0d6287-7539-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u67efc5a0&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u65cde068-6ef7-4dca-87da-d178eb5d892&title=)

回到Controller，给前端抛出“基本信息VO类”即可

关注与粉丝

注：getAccountInfo & getUserInfo

    ==**>查询 用户信息 / 基本信息 代码逻辑基本一致，返回给前端内容不同，两者也实现了解耦**。

四、理论：缓存双写！

【理论】浏览器缓存介质

1 概述

（1）为什么要对“基本信息”优化？

基本信息在 “很多页面” 都会用到，一个重复的数据，可能会在很多页面重复调用。所以这个 getUserInfo 的接口方法压力其实挺大的.
有没有一种方式降低压力？
==> 因为“基本信息”改动频率很低，所以我们把它【存在服务器上】

（2）一种存储情形

    如下，session stroage 存的就是基本信息：<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655826684783-5ba64dac-7533-4d6e-8d25-04d51aa4ad12.jpeg#clientId=u1c0d6287-7539-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u3fcf3f75&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u26c3005e-1f9f-46fe-b6dd-5e4e3fda901&title=)<br />        这一步，代码中也有体现：<br />        （注意看灰框中的注释，存到了“session stroage ”）<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655826684784-c60d8e35-372b-438e-a1e8-33e7a3e098e9.jpeg#clientId=u1c0d6287-7539-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u9d051072&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u9ddcad8c-5139-4b90-bd12-beb78860885&title=)

2 浏览器存储介质的几种方式

（打断点这块跟老师做一下）

（1）cookie

    浏览器存储介质其实本质上也可以称之为缓存，比如cookie，就是早期我们使用最多的，目前用户的 id 以及 token 也是保存在cookie 理的。<br />        通过保存数据后，那么可以获得并且和后端服务器交互。<br />        Cookie是保存在浏览器的，如果不设置过期时间，那么cookie会保存到内存，如果浏览器关了，那么cookie就没了，这也起到了会话的作用。如果我们设置了过期时间，那么cookie会保存在硬盘，关闭浏览器cookie还会存在，直到过期，一般7天重新登录或者1个月免登录都是这样的。<br />        cookie 中只能存一些字符串类的内容，对象或list以json字符串去保存，但是需要注意，cookie有大小限制，4k左右，所以一般不会设置很大的数据放到cookie中。

（2）webStorage

在HTML5以后，那么浏览器可以使用 webStorage ，其实也是类似一种数据存储的表现形式，是对cookie的一种改良。

1. sessionStorage：数据可以保存到session对象中。session是指用户在浏览某个网站时，从进入网站到浏览器关闭的这一段段时间，称之为会话。session中可以保存任何数据。

2. localStorage：数据可以保存在客户端本地磁盘中，就算浏览器关了，数据还是会存在的，重启电脑，下次打开网站，数据还是能获取。这相当于数据持久化的一种表现。

   sessionStorag 和 localStorage 的区别就是，sessionStorage是临时保存，localStorage是永久保存持久化。
   他们的数据存储在 5m 左右，比 cookie 大很多（能存4K左右）。
   安全方面也比 cookie 好，因为不会被携带到请求中，通过 webStroage，大多网站数据进行缓存后，可以更快加载，也能为并发减轻一定压力。

   优化 getUser & updateUserInfo ：在 Redis 中缓存用户信息 + 更新 mysql 时同步更新redis

   之前虽然已经通过 sessionStorage 对“基本信息”进行了优化（这个操作是什么时候做的？？？？前端做的吗？？？），但是用户如果已经知道地址，还是可以发起高频率的请求.
   因为“基本信息”基本不更改的特性 ==> 我们可以把基本信息存入到 Redis 中去！这样用户查询时，直接去缓存Redis中查询即可，不用再进入数据库了

   代码

   由于用户信息不怎么会变动，对于千万级别的网站，这类信息数据不会去查询数据库，完全可以把用户信息存入redis。
   哪怕修改信息，也不会立马体现，这也是弱一致性。在这里有过期时间，比如1天以后，用户信息会更新到页面显示，或者缩短到1小时，都可以； 基本信息在新闻媒体类网站是属于数据一致性优先级比较低的，用户眼里看的主要以文章为主，至于文章是谁发的，一般来说不会过多关注.

    private AppUser getUser(String userId) {
        String userJson = redis.get(REDIS_USER_INFO + ":" + userId);//1 尝试从redis获取
        AppUser user = null;
        //2 查询判断redis中是否包含用户信息，如果包含，则查询后直接返回，就不去查询数据库了
        if (StringUtils.isNotBlank(userJson)) {
            user = JsonUtils.jsonToPojo(userJson, AppUser.class);
        } else {
            // 3 说明 redis 
            无，去 mysql 中搞
            user = userService.getUser(userId);
            // 由于用户信息不怎么会变动，对于一些千万级别的网站来说，这类信息不会直接去查询数据库
            // 那么完全可以依靠redis，直接把查询后的数据存入到redis中
            redis.set(REDIS_USER_INFO + ":" + userId, JsonUtils.objectToJson(user));
        }
        return user;
    }

...
    //缓存双写那里还要更新！！这就不展示了！

1 扩展 UserController 的 getUser 方法：增加初次查询放入缓存的功能

（1）定位 getUser

    打开 UserController 里获取“基本信息”的方法，里面有一个getUser；找到这个方法，进行扩展！

（2）设置 redis 所需的 key 值

    这里 redisController 用到一个key，这个玩意我们去BaseController中去设置一下，如下：<br />        redis_user_info

（3）导入第三方工具类

    把 user 信息放到 value 的位置，需要 **JSON 转换类 ，把对象转成 str**.<br />        这个类从老师源码中拿即可，放入 common 中的 utils 包中即可<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655826684765-060a18d3-f736-4038-a7c4-e4a7bc42530b.jpeg#clientId=u1c0d6287-7539-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u63f6e038&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=ubbf2926e-f754-4ae2-bc3e-65f91343020&title=)

2 更改 userServiceImpl 中的 updateUserInfo 方法：补充修改信息时，同步更新缓存的逻辑（未完待续）

（ 注意是 service 层 而不是 controller 层，虽然两层方法同名）
（之前只更新在了数据库，现在为了配合查询的方法，现在还要更新到Redis中）

（1）为什么

    之前用户修改了信息以后，**只是存在了数据库中**！<br />        **如果不同步覆盖 redis 中的数据，那么 1 中的方法从 redis 中读取的可能就是脏数据了！**

（2）怎么做

    这个方法，我们最后“补充一个查询”.<br />        “把最新的信息放入redis中”.<br />        补充后代码如下： userId 得从 BO 中获取，这句代码也别忘了.<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655826685788-930db62e-3868-4667-bbd7-597f428fb13d.jpeg#clientId=u1c0d6287-7539-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=ud84dd712&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u129b2414-c388-407e-a25d-6ea2b5a818b&title=)

【理论/重要】双写数据不一致的情况

1 啥是：缓存双写
由于分布性系统，不能保证每个节点都可用，所有可能引起 redis 在极限情况下数据没有写入成功。那么此时缓存中的数据和数据库数据不一致。
这样的情况，同步存入 redis 的过程就可能产生问题：数据没放进redis中！

具体见老师笔记：拓展阅读https://www.imooc.com/wiki/imoocnewsarchitect/BothWriteEqual.html
如下图，“数据库中修改成功了，但是redis修改失败了”

优化 updateUserInfo：双写缓存不一致 + 缓存双删

    本节开始解决上节课提到的“双写不一致的情况”。

代码

@Override
    public void updateUserInfo(UpdateUserInfoBO updateUserInfoBO) {
        String userId = updateUserInfoBO.getId();
        // 【本节继续优化1】保证双写一致，先删除redis中的数据，后更新数据库.
        redis.del(REDIS_USER_INFO + ":" + userId);
        AppUser userInfo = new AppUser();
        BeanUtils.copyProperties(updateUserInfoBO, userInfo);
        userInfo.setUpdatedTime(new Date());
        userInfo.setActiveStatus(UserStatus.ACTIVE.type);
        int result = appUserMapper.updateByPrimaryKeySelective(userInfo);
        if (result != 1) {
            GraceException.display(ResponseStatusEnum.USER_UPDATE_ERROR);
        }
        // 【上一部分刚优化】再次查询用户的最新信息，放入redis中
        AppUser user = getUser(userId);
        redis.set(REDIS_USER_INFO + ":" + userId, JsonUtils.objectToJson(user));
        // 【本节继续优化2】缓存双删策略
        try {
            Thread.sleep(100);
            redis.del(REDIS_USER_INFO + ":" + userId);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

1 双写不一致：更新 mysql 时删除 redis，使得 redis 必须去 mysql 读取数据再存入

（1） 思路分析

如何避免“双写不一致”的呢？
<1> 发起修改请求时，【先删除 redis 中过的数据】
<2> 删除后才更改数据库
<3> …后续就是再写入redis
redis中数据删除后，在重新写入前，如果用户此时访问了，【就和我们之前写的逻辑一样：redis中没有时，去数据库中查询】

（2） 代码实现：补充删除代码

2 缓存双删：优化双写不一致

（1） 问题反思

此时，分析一下，还有什么遗漏的问题。假如，用户的请求在 “ redis删除之后，mysql更新之前 ”，那么此时 redis 去 mysql 中拿到的数据，还是旧数据。如何避免？

==> 引入【缓存双删】：mysql “更新时”删一次，”等一会”再删除一次
我们在 mysql 更新后，【所在线程休眠半分钟左右，然后再次删除redis中的数据】，然后再更新。
注：这样的做法仍然是不能完全解决“脏数据的问题”，只是【很大程度上压缩脏数据的存在时时间】！！！因为对于用户来说，做到这样其实也已经足够了，这个业务并不是说，用户晚几秒看到用户信息就不能接受之类的。

（2） 代码实现

【理论】业务角度分析：为何可以容许脏数据存在？

一些情况下，业务不能受到并发影响，如果出现了 1~2秒 的脏数据，我们在首页展示的用户信息可能是错的，但是这个对整个系统的完整性是没有什么影响的，所以“保证系统可用性即可！！！”

——> 不能把太多的请求放在数据库.
从业务角度分析：并发请求绝大多数在首页和新闻详情页，用户的查询是很多的。如果出现了1-2秒的脏数据缓存，那么首页展示的用户昵称或者用户头像可能是老数据，但是对于整个系统来讲无所谓，没有太大的影响，而且用户的注意力是在新闻上，而不是新闻发布者，所以有几秒的不一致是无所谓的，因为热点数据的并发读是很大的，一旦删除，那么这个时候由于缓存击穿，数据库可能会瞬间被炸了，直接宕机。所以务必以系统可用性为优先考虑。

（？？？？什么是缓存击穿？？？？？？？？）
（卧槽，感觉挺重要的，但是没听懂啊，啥叫“并发读”）
==> 因为对于这个项目，重点在于“看文章”，发布者如果信息有1-2秒错误的话，没有什么关系。
因为热点数据的 “并发读” 是非常大的，一旦删除之后，用户有大量的并发请求进来，可能造成“缓存击穿”，数据库可能瞬间爆炸。所以保证系统更可用性更加重要，几秒的脏数据没什么关系。

==>涉及到CAP理论，下节课讲解！

【理论】CAP理论

上节课最后提到了CAP理论，本节详解。
———————————————————————-

1 CAP 简介

分布式系统由多个组成部分共同构成，**用户的请求通过不同节点的多次运算后才能把结果响应给用户，也意味着请求经过了多个系统**。<br />    **分布式系统，都有CAP的情况。**<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655826723830-0b4b2535-ffb4-4547-931d-0f7a06ee1323.jpeg#clientId=u1c0d6287-7539-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=udd2546bc&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=ua3a78270-4605-4f7f-aa97-21396c8a448&title=)<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655826724591-52b655aa-5c58-428d-bc68-0998048cad62.jpeg#clientId=u1c0d6287-7539-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u4c679ea0&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u27cb5dac-172e-4e06-bd57-d07ead5b596&title=)<br />        云服务器在不同地方，这就是“网络分区”。<br />        分区之间有通信。部分系统故障不影响整体。即考虑“分区容错”<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655826723903-7f68d961-92bd-4877-abe1-a3bae19857ef.jpeg#clientId=u1c0d6287-7539-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=uca125046&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=udd70137b-ddc1-449a-8609-df90d1b07c8&title=)<br />理论上应该都满足，但实际上，因为人开发了系统，难免有错，**所以一般【只能满足CAP中任意两个】**<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655826724060-8c858ce1-4245-45b2-add9-628d9ca35a2c.jpeg#clientId=u1c0d6287-7539-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=uefcfaaad&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u4cb89233-468c-40f8-918c-c147185387c&title=)

2 为何无法同时满足CAP？

（看视频讲解即可）

==> 开发中，都是保证好P（分区容错性）以后，采取抉择保证C（一致性）还是A（可用性）

3 各搭配分析

1 介绍
CP：效率低
redis mongoDB这种都是CP，强一致性，效率低
AP：多用（可用性 + 分区容错性）
CA：一般都是关系型数据库才用，一些单体的数据库

日常中，一般都关注“弱一致性”，强一致性难满足，用户对一般的业务也不太关注一致性。
但是数据服务一定要满足强一致性。

2 项目首页体现“弱一致性”
首页高访问，所以“优先保证可用性”，一致性可以延后处理。
（？？？这个为啥刷新了还不出来，不是已经重写了那个方法码？为啥非得重开一个会话才读取后端数据？？？==>最后老师讲了，如下，首页基本信息这里有一句“数据存入seesion storage”，估计更改信息的页面没有这句话，估计实时获取）

4 弱一致性（具体见老师笔记）

五、拦截器验证用户合法性

**有些接口是需要用户登录以后才能操作**，比如用户发布文章。如果随随便便一个用户调用接口，会有问题。**所以我们需要构建拦截器来验证一下用户是否合法，只有合法用户才能放行**。

用户会话拦截器

目前我们已经写了几个接口，只要涉及到接口，我们就需要考虑到 “**有些接口在用户登录时才能去访问**” <br />==> 这就需要设置拦截器。<br />    本节，我们就给现有接口配置拦截器.
其实我们之前已经配置过拦截器了，位置如下：这个就是控制短信的<br />    现在我们需要控制“用户会话”的。只有用户在登陆，或者注册完毕以后，相应的有了**token、会话信息**，则相应的接口必须在被访问时进行拦截，必须在“用户登陆以后”才能调用这些接口！

1 创建“用户拦截类”

    创建如下：UserTokenInterceptor<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830233255-c90ba36b-ea26-4ed1-bf5e-e058cc7c4fb5.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=uaf1d282d&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u8b3a4d32-f635-4037-a6ca-32b51fc0e62&title=)

2 实现拦截方法1

**拿到 id 和 token.**<br />    注意，这里我们**直接从 header 里面获取**。为什么不从 cookie 里获取？因为就 H5 端有 cookie ，IOS 或者安卓端没这个东西，所以为了提高泛用性，我们就从这里面获取。（header和cookie共有的数据有哪些呢？？？？）<br />    拿到以后，判断是否放行，根据 id 和 token 到 redis 中去做查询和验证。因此，我们这里写一个共用的方法：**专门验证 id 和 token！！**见（3）

3 编写“验证放行的方法”

当前包下再创建一个类：**BaseInterceptor**，在里面写验证方法。<br />    **传入id token 和 key** (key就是我们以前写的常量，复制过来)。<br />    ......<br />     需要用到redis，注入一下.<br />    ......<br />    不空时，拿到 redis 里的 token 以后，里面还要判空，因为可能过期了；如果还不是空的，才去判断是不是相等. <br />        ......<br />        编写好后，如下：<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830233224-762c9bc3-2b85-41e4-8dee-fe7ff0564127.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u8ffcd127&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=ua18602d3-f7f1-47c1-8841-cce4f9927c6&title=)<br />（这个方法后面 admin 管理系统也会调用，所以抽出来了）

4 实现拦截方法2

    拦截器继承刚刚写好的这个类：<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830233220-90fbe558-e25a-43ec-a915-ad8314e7b8b0.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u6b06e4f8&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u4b1ea8fb-70f6-406c-ba20-dfcae0897fe&title=)<br />    补充判断放行的逻辑：<br />    （第三个形参是前缀，BaseInterceptor 中也已经声明了，拿来用）<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830233205-fdd8045e-d71d-49fa-ab89-95687a77ce09.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u3a34d6a0&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u912bd0e6-50da-40de-8a93-1175273884c&title=)

5 配置拦截器

打开 interceptorConfig<br />        ①配置Bean<br />        ②注册拦截器（add方法中）<br />想一下哪些接口目前需要被拦截到？<br />    <1>如下这个更新<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830233761-2d4cecc0-49fc-4931-8656-1957eaddf809.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u72042e61&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u6c0c1868-a743-4dbf-b49a-11d5c650486&title=)<br />    <2> 获得账户信息的请求.<br />    <3> **获得用户基本信息需要被拦截吗？==> 这个信息不需要，这些基础信息就是给别人看的；**<br />另外，从首页头像点进去看到的是别人的个人中心页面首页，看人家文章信息啥的，这都是基本信息，这些别人不登陆，你也可以查看！<br />（点首页那个头像进去）<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830233743-c0efa163-e363-4b9f-abbd-48fdff954f0a.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=uc5d8a609&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=ua269e851-b4bb-46b4-bcfd-de79b20b192&title=)<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830233760-feba13a0-cdfb-4e67-8a60-08c5f1599d99.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u20c10eb9&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u4be8eb14-9302-4c65-93b6-68bf195f2dd&title=)<br />...<br />写好后如下：<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830233851-bbb4d5c3-04c5-43d7-9205-c5d80a32ef85.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=uf7aa0931&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=ub5feec84-c557-474e-8fb2-6128ad70a07&title=)

用户状态激活拦截器

本节扩展新的拦截器。
用户发表文章、修改文章、修改评论这些接口（和网站 有交互性动作），需要用户处于激活状态才可以调用！

1 创建拦截器类：UserActiveInterceptor

    如下图：<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830234289-2336242b-a9ff-4a40-9a8e-3f9969d6111e.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u421e73f3&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=ufd2b2fe6-1119-45c5-8356-7e440f8c75f&title=)

2 完善拦截器

要去验证用户的信息，用户登陆注册以后本身需要进行查询（即getUser方法），此时信息已经存入 redis 中了.<br />    ∴ 这里直接通过redis获取（写法参考之前）<br />    为了能够在这里直接调用 redis，需要回去 BaseInterceptor 中，把 private 改成 public.<br />    然后Key的前缀也复制过来：<br />    （两处改动如下）<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830234300-30b8f868-a18f-413d-a075-9ac129c57cee.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u68251b18&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=udce85e76-46c8-42c3-964c-aad89312415&title=)<br />-----<br />        preHandler中拿到信息后，进行判断：先看看激活信息是否为空，再看看是否激活。状态如果有问题，直接抛出异常<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830234356-88589de3-5bb5-42f5-af71-d4c7e58d6f29.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u7db1b6d9&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=ud1359104-c133-478a-8036-cabe29e7c60&title=)<br />至此，该拦截器初步完成.

3 思考（5：20）

    这里讲了一下preHandle判空后是否需要加 else 进行额外的查询<br />        ==> 这里的意思是：**如果 redis 中没有数据，是否有必要向 mysql 发起请求，把这个信息拿到，并储存到 redis 中去**？（之前的缓存双删部分的内容）<br />回答：<br />        没有必要！**用户注册和登陆执行了以后，必然会保证 redis 中有数据**！<br />        如果不放心，可以把向 redis 存储数据的请求放到dologin中！如下图，登陆成功且不是冻结状态，99行，执行这个存储redis的操作：即保存了用户的会话信息以后，再次保存了用户本身的信息！<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830234471-9f65d2c6-49fe-4a0c-a104-16ea8fe834fd.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u610cecb2&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u14fbe7ab-c32c-4aaf-a2c3-bd71c43b871&title=)

4 补充用户没登陆时的报错

     if 的 else 里.<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830234440-1a096c1b-3293-4b74-a99d-f9bf6fed5d94.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u6e86ca7c&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u294d967a-b78c-40c5-a380-9531dc40094&title=)

5 拦截器配置文件中注册

    激活拦截这里，先注释掉！后续我们如果有需要，再回来添加！<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830234796-45f86f96-1baf-46a3-b9e0-13ab30c92476.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=udee7af7c&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u1b73cf7b-6db3-4492-a3e1-27723861828&title=)

六、完善剩余功能

AOP警告日志监控

1 引

目前，项目有一个service：UserService

这里有一些相应的方法

现在我们有一个需求：
想知道service在执行某一个方法的时候，花了多久的时间，根据时间输出不同的日记.
比如，如果执行时间长，我们就爆出一个警告…
==>需要用到AOP切面编程

2 AOP编程

（1）确定 AOP 作用范围

    我们要拦截的就是 com.imooc.*.service.impl 包的所有类，其中 * 就是不同的业务会在后续创建不同的包。<br />        为了在所有后续添加的服务中都可以进行切面编程，进行拦截判断，我们就需要把“**切面配置在 api 工程**”<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830469576-250e8e49-b8b6-482f-8b7e-abd7f3a9cb6d.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u2642a3e0&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u05a0d99c-cd72-4811-a027-6374e5d2203&title=)

（2）创建日志切面类

建个包如下图

再来new一个java类

（3）去 common 的 pom 添加 aop 的依赖

（4）创建日志切面类

    加aspect，标明是切面<br />        加component，可以被注入容器<br />        写一个日志：<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830470191-f45f5edc-49f3-4211-99bb-e481f04afe22.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u43f935f2&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u566bf4e6-5d3f-4e39-b35d-7db799398a7&title=)<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655830470307-37a8d527-c936-4bcb-ae76-6d0f15d43dfa.jpeg#clientId=u180cf55e-9618-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=ude06ade5&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=uae71a0c7-80ee-4008-bd23-79d48b8acd2&title=)

（5）回忆AOP通知：5种

我们使用的是第三种：环绕通知

（6）环绕通知1：切面表达式

    首先需要正确书写“切面表达式”<br />        表达式写在around注解的execution中<br />        写法如下：                        * 根据业务改变； <br />                     最后 `..` 代表impl当前包及其子包中的所有.<br /> <br />                     最后还有：`*.*(..)`  <br />             第一个 * 代表类名；<br />            . 代表类的某一个方法，*代表所有方法；<br />             最后 (..)：方法形参任意

（6）环绕通知2：验证切面表达式

写出方法轮廓后，左侧又出一个“红色的M”

点击这个m，里面有4个方法

这4个方法就是我们写在service中的方法，如下图：

这就说明我们的切面表达式写的是正确的，有问题的话，点这个出不来

（7）环绕通知3：实现方法

形参为“切入点”.
①
开始写打印 log 的方法；其中 通过 切入点对象 获取类名，方法名等信息……
② 开始时间，结束时间，得花费时间，时间超过3s，暴一个高级别错误；大于2s时，暴一个警告；
③ 中间调用 proceed 方法表示方法执行；
返回一个object对象，我们最后直接return出去

（看return）

④ proceed报出异常，我们在方法上抛出

至此，方法写的差不多了..

SQL打印

Service 层的另一种调试方式：针对执行的 sql 语句

（1）开启 dev 环境 mybatis 日志打印

    这个需求主要是在 dev 环境，prod环境没必要.
    编写如下：

（2）重启测试（18：30）

跟着老师学怎么看结果

退出登录 并 注销会话

    通行证服务的最后接口：退出登录。首页这里就能退出登陆：

    退出登录主要就是：清除登陆信息，包括 redis 中的和 cookie 中的.
    这两块内容清除就退出登陆了.
    （？？cookie是自动就配好的吗？redis确实是我们自己设置的 ==> cookie也是在dologin方法中设置的）

1 PassportControllerApi 中补充接口

    需要传入一个参数：userId，有这个才能找到要删除的信息.
    这个形参别忘了加上 @RequestParam，否则不好执行.

2 Controller中实现接口

（1）删除 redis 中的信息

    首先清除redis中的数据，根据 常量属性 和 id 拼接出 用户的 token.
    删除这个之后，思考一下 ...USER_INFO 有必要删除吗？  没必要，这个是没有必要的，因为其他应用可能还会用到基本信息。而token这个只与登陆相关，所以推出登陆时删掉就完事了.

（2）删除 cookie 中的信息

     然后清除 cookie。这个没有del方法，所以通过设置过期时间为0的方法来达到删除的目的。
    之前在 BseController 中有一个 COOKIE_MONTH ，我们这里来定义一个 COOKIE_DELELTE，设置为0。
    在 setCookie 方法中传入即可。cookievalue这个形参直接用一个空字符串来替换即可.

第四章 文件服务

分布式文件系统

什么是分布式文件系统

• 随着文件数据的越来越多，通过 tomcat 或 nginx 虚拟化的静态资源文件在单一的一个服务器节点内是存不下的，如果用多个节点来存储也可以，但是不利于管理和维护，所以我们需要一个系统来管理多台计算机节点上的文件数据，这就是分布式文件系统。
• 分布式文件系统是一个允许文件通过网络在多台节点上分享的文件系统，多台计算机节点共同组成一个整体，为更多的用户提供分享文件和存储空间。比如常见的网盘，本质就是一个分布式的文件存储系统。虽然我们是一个分布式的文件系统，但是对用户来说是透明的，用户使用的时候，就像是访问本地磁盘一样。
• 分布式文件系统可以提供冗余备份，所以容错能力很高。 系统中有某些节点宕机，但是整体文件服务不会停止，还是能够为用户提供服务，整体还是运作的，数据也不会丢失。
• 分布式文件系统的可扩展性强，增加或减少节点都很简单，不会影响线上服务，增加完毕后会发布到线上，加入到集群中为用户提供服务。
• 分布式文件系统可以提供负载均衡能力，在读取文件副本的时候可以由多个节点共同提供服务，而且可以通过横向扩展来确保性能的提升与负载。

为什么要使用分布式文件系统

使用分布式文件系统可以解决如下几点问题：

1. 海量文件数据存储
2. 文件数据高可用(冗余备份)
3. 读写性能和负载均衡

以上3点都是我们之前使用tomcat或nginx所不能够实现的，这也是我们为什么要使用分布式文件系统的原因.

文件存储的形式

• 传统服务器存储
• FastDFS
• OSS
• GridFS

阿里云 OSS

文件上传

图片自动审核

第五章 admin 管理服务

本章节主要包含内容为如下：

• 包含分类管理
• 管理员账号管理
• 友情链接管理
• 文章内容人工审核
• 网站用户管理

创建 module：imooc-news-dev-service-admin
文章内容这里先不做：后续会完善自动审核，自动审核不通过的人工再审核.
admin管理人员账号这里是“需要分配的”，一开始有一个admin账号，然后就可以给新的admin账号分配权限。同时除了通过用户名和密码登陆，还可以实现人脸识别登陆，人脸对比后，先让人脸入库，后续可以用人脸进行对比.

§ 5.1.1 admin 账号登陆

手动创建第 1 个 admin 账户

1 查看 admin 表结构

开发业务前，看看数据库列表.
我们这里 admin 和 app 用户是两张表：

字段如下：
faceId 对应 mogoDB 中的人脸文件，搞到 mongoDB 里去.

2 创建初始 admin 账号 + 加密密码

因为 admin 没有 “注册” 这一概念，都是 “预分配”：手动创建admin账号。然后通过 admin 再创建一些其他的账号.

密码需要涉及加密，去 java 里面写一下.
controller 城里面创建 PWDTest 类，api工程中加入spring的一个依赖（看笔记或者视频），然后就可以调用 BCrypt 这个类了。
我们并不是直接加密密码，而是先搞一个【salt】（hashpw中第二个形参），然后和密码（hashpw中第一个形参）一起放到 hashpw 方法中。当然老师这里用的是 “明文：admin作为密码”，实际上的话，这里最好把密码先用 【md5 加密】，然后再作为形参传入，再加盐。
这里，编写完代码并打印，如下：

String pwd = BCrypt.hashpw("admin", BCrypt.gensalt());

我们把这段拷贝到数据库中去：
ID1001，用户名admin，密码刚才生成，然后其他的如图：

持久层查询管理员：mapper和service

看看admin登陆页，人脸识别先不管，我们需要先写相应的 service 和 controller。<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655870009547-624b1a3c-118d-4920-844f-5c00651c7604.jpeg#clientId=uf918a9c4-1e40-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=ucdcc04cf&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=ucbae391d-3385-4a69-af01-bf6ad8bfad3&title=)

一、创建mapper

    打开项目，打开如下 admin.xml 文件：<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655870009558-7f5ba744-6386-4b3b-a1c6-840b7b246a2c.jpeg#clientId=uf918a9c4-1e40-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=uc70cd773&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=uad8a7ea0-7d4c-454d-b95a-7fbc644d758&title=)<br />        需要配置对应的表：如下改成mysql中的表名即可.<br />        生成即可，这里都生成好了.<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655870009565-b5a7be79-57de-459e-91c3-286890c9a978.jpeg#clientId=uf918a9c4-1e40-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u9664a41d&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=uaa6f19ed-7d52-42d2-978a-1157d44a14e&title=)<br />运行如下位置的 adminJava 类：<br />![](https://cdn.nlark.com/yuque/0/2022/jpeg/23211485/1655870009581-bf5d8901-a3ab-44b0-8f48-708a48f8e111.jpeg#clientId=uf918a9c4-1e40-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u0e55b841&originHeight=281&originWidth=500&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=ud7dcfc1b-1861-474c-9df8-9e12745c748&title=)<br />    运行成功后，相应的 mapper 啥的就都生成好了，我们都拷贝到 admin 项目中去.。宝库mapper（放到admin项目） + pojo类（放到model层） + mapper.xml文件（admin中的resource）

二、创建service：【根据用户名查询】（业务上，用户名唯一）

写对应方法：用来查询：【根据用户名查询】（业务上，用户名唯一）.
查询后，把 adminUser 对象返回给 controller 层，然后在 controller 层就可以密码校验.

Example是针对 adminUser 的一个“查询实例”（==>mybatis提供的吧）。Criteria可以封装“查询条件”。Example ，其中就包含了刚才写的 “判断条件” 。返回一个 Appuser（这个和我们创建 example 时传入的类对象是一致的），不存在时，AdminUser 为 null。

    @Override
    public AdminUser queryAdminByUsername(String username) {
        Example adminExample = new Example(AdminUser.class);
        Example.Criteria criteria = adminExample.createCriteria();
        criteria.andEqualTo("username", username);
        AdminUser admin = adminUserMapper.selectOneByExample(adminExample);
        return admin;
    }

用户密码登陆：controller层

紧接上节，编写controller

登陆界面的 用户名 和 密码 是在表单里面的，可以作为 BO 传入.
当然只是这样 是不行的，用户登陆以后，cookie 和 token 这种我们也都是要设置的！

登陆信息BO验证

@Override
    public GraceJSONResult adminLogin(AdminLoginBO adminLoginBO,
                             HttpServletRequest request,
                             HttpServletResponse response) {
        // 0. TODO 验证BO中的用户名和密码不为空
        // 1. 查询admin用户的信息
        AdminUser admin = 
            adminUserService.queryAdminByUsername(adminLoginBO.getUsername());
        // 2. 判断admin不为空，如果为空则登录失败
        if (admin == null) {
            return GraceJSONResult.errorCustom(ResponseStatusEnum.ADMIN_NOT_EXIT_ERROR);
        }
        // 3. 判断密码是否匹配
        // 判断存在时，从数据库中获得密码，与输入的BO中的密码匹配一下.
        boolean isPwdMatch = 
            BCrypt.checkpw(adminLoginBO.getPassword(), admin.getPassword());
        if (isPwdMatch) {
            //如果数据库中有，则登录成功，并且设置admin的会话以及cookie信息即可。
            doLoginSettings(admin, request, response);
            return GraceJSONResult.ok();
        } else {
            return GraceJSONResult.errorCustom(ResponseStatusEnum.ADMIN_NOT_EXIT_ERROR);
        }
    }

登陆成功时，设置 redis token cookie 信息

/**
     * 用于admin用户登录过后的基本信息设置
     * @param admin
     * @param request
     * @param response
     */
    private void doLoginSettings(AdminUser admin,
                                 HttpServletRequest request,
                                 HttpServletResponse response) {
        // 保存token放入到redis中
        String token = UUID.randomUUID().toString();
        redis.set(REDIS_ADMIN_TOKEN + ":" + admin.getId(), token);
        // 保存 admin 登录基本 token 信息到 cookie 中
        setCookie(request, response, "atoken", token, COOKIE_MONTH);
        setCookie(request, response, "aid", admin.getId(), COOKIE_MONTH);
        setCookie(request, response, "aname", admin.getAdminName(), COOKIE_MONTH);
    }

§ 5.1.2 admin 账号创建（添加管理员）

【业务介绍：添加管理员】
之前已经完成了admin的用户名密码登陆，登陆完后，可以设置管理员！

这个登陆名啊，我们之前说过，应该保证唯一性。
在配置这个之前，可以测试一下：输入不合理时，前端这里也是有一些事件可以触发的.
如下：

所以，这款一块是需要我们编写接口的.

校验 admin 账号“唯一性”

本节处理第一个功能：admin用户名“唯一性”验证

代码

该代码原来不是单独就有的，这里为了以后方便调用，单独抽出来了.

    @Override
    public GraceJSONResult adminIsExist(String username) {
        checkAdminExist(username);
        return GraceJSONResult.ok();
    }
    //得到用户名，判断是否存在，为方便调用，解耦出来
    private void checkAdminExist(String username) {
        AdminUser admin = adminUserService.queryAdminByUsername(username);
        if (admin != null) {
            GraceException.display(ResponseStatusEnum.ADMIN_USERNAME_EXIST_ERROR);
        }
    }

补充拦截器

我们现在已经登陆了，那么相关的操作，必须由【拦截器】进行拦截！保持用户是登陆的状态.
大家参考之前写的拦截器userTokenInterceptor，自己完成adminTokenInterceptor.

创建了interceptor，后面别忘了注册.

（代码老师直接提供在工程中）

创建 admin 账号

看到下面的确认添加了吗？本节就完成这个功能！

说白了就是把这里的数据发到后端，也可以将其作为一个BO的数据将其传过去。人脸数据现在还涉及不到，是以一个 img64（没听懂）的字符串传入的，这个后面再说.

添加BO

直接拷贝。里面的img64就是老师说的啥啥64那玩意。img64和faceId暂时用不上

创建 admin ：controller 层

@Override
    public GraceJSONResult addNewAdmin(NewAdminBO newAdminBO,
                                       HttpServletRequest request,
                                       HttpServletResponse response) {
        // 0. TODO 验证BO中的用户名和密码不为空
        // 1. base64不为空，则代表人脸入库，否则需要用户输入密码和确认密码
        if (StringUtils.isBlank(newAdminBO.getImg64())) {
            if (StringUtils.isBlank(newAdminBO.getPassword()) ||
                    StringUtils.isBlank(newAdminBO.getConfirmPassword())
            ) {
                return GraceJSONResult.errorCustom(ResponseStatusEnum.ADMIN_PASSWORD_NULL_ERROR);
            }
        }
        // 2. 密码不为空，则必须判断两次输入一致
        if (StringUtils.isNotBlank(newAdminBO.getPassword())) {
            if (!newAdminBO.getPassword()
                    .equalsIgnoreCase(newAdminBO.getConfirmPassword())) {
                return GraceJSONResult.errorCustom(ResponseStatusEnum.ADMIN_PASSWORD_ERROR);
            }
        }
        // 3. 校验用户名唯一    （上部分的逻辑，直接到用单独写的那个方法）
        checkAdminExist(newAdminBO.getUsername());
        // 4. 调用 service 存入admin信息
        adminUserService.createAdminUser(newAdminBO);    //代码在下边
        return GraceJSONResult.ok();
    }

创建 admin ：service 层

@Transactional //别忘了加“事务注解”
    @Override
    public void createAdminUser(NewAdminBO newAdminBO) {
        //①（sid主键生成啥的？？==>嘶，是不是之前讲过分布式系统中的全局唯一ID那讲的？？？）
        String adminId = sid.nextShort();
        AdminUser adminUser = new AdminUser();
        adminUser.setId(adminId);
        adminUser.setUsername(newAdminBO.getUsername());
        adminUser.setAdminName(newAdminBO.getAdminName());
        //② 密码这里需要判空，不空时才加入
        //（？不是那啥，前面，难道没有判空吗？你这写了密码判空，那我前面还需要密码判空吗？）
        // 如果密码不为空，则需要加密密码，存入数据库
        if (StringUtils.isNotBlank(newAdminBO.getPassword())) {
            String pwd = BCrypt.hashpw(newAdminBO.getPassword(), BCrypt.gensalt());
            adminUser.setPassword(pwd);
        }
        //③ 设置faceID，前端提交信息的时候其实还有人脸信息的，不为空时需要设置这个，后面详细说.
        // 如果人脸上传以后，则有faceId，需要和admin信息关联存储入库
        if (StringUtils.isNotBlank(newAdminBO.getFaceId())) {
            adminUser.setFaceId(newAdminBO.getFaceId());
        }
        //④ 设置时间
        adminUser.setCreatedTime(new Date());
        adminUser.setUpdatedTime(new Date());
        //返回
        int result = adminUserMapper.insert(adminUser);
        if (result != 1) {
            GraceException.display(ResponseStatusEnum.ADMIN_CREATE_ERROR);
        }
    }

讨论：为什么这里不能直接存入 人脸信息？

用户人脸信息为什么不存入数据库，要存入mogoDB？
这个 base64 字符串太长了，存到数据库不适合，会放到 gridFS 去（这啥？）.
也不能存入OSS，不然会公网暴露URL（？？？）.
==>需要“私有读”，gridFS这方面好一些

§ 5.1.3 admin 账户列表

本节做【查询admin列表】。页面下方有个列表：我们发现还需要分页

controller ：getAdminList 方法

    @Override
    // 涉及到分页，传入“第几页” “每一页要显示的数量”.
    public GraceJSONResult getAdminList(Integer page, Integer pageSize) {   
    // 首先判断一下这俩形参，因为这俩是“非必填选项”，所以空的时候，来一波默认赋值.        
        if (page == null) {
            page = COMMON_START_PAGE;//常数，因此我们把这俩抽离出来放到 baseControlller中
        }
        if (pageSize == null) {
            pageSize = COMMON_PAGE_SIZE;
        }
        PagedGridResult result = adminUserService.queryAdminList(page, pageSize);
        return GraceJSONResult.ok(result);
    }

BaseService 中分页数据封装方法：setterPagedGrid

前端这里分页组件，需要后端提供数据，计算这回才在这显示这些数字链接供我们点击。如当前第几页，查询了多少条记录。
这些功能都要封装，然后返回给前端，让前端进行相应的渲染：列表和分页组件效果.
Service层封装分页数据，这里写一个统一的方法，因为后面不仅仅是这里使用分页的方法。

其中这个rows，就是我们查询出来的数据，与在 controller 中调用 service 返回的查询结果 list 是匹配的。

// 形参这个List就是对应我们从service层查询返回的结果，为了通用性这里使用泛型.
public PagedGridResult setterPagedGrid(List<?> list,
                                            Integer page) {
        //PageInfo里面的属性很多，我们用不了那么多.  （老师提供的工具类） 
        PageInfo<?> pageList = new PageInfo<>(list);    //PageInfo类
        //PagedGridResult，于下部分.
        //这里 getPage getTotal 都是插件内部的一些方法，会帮我们计算页码.
        PagedGridResult gridResult = new PagedGridResult();     
        gridResult.setRows(list);
        gridResult.setPage(page);
        gridResult.setRecords(pageList.getTotal());    // getTotal
        gridResult.setTotal(pageList.getPages());    // getPage
        return gridResult;
    }

/**
 * @Title: PagedGridResult.java
 * @Package com.imooc.utils
 * @Description: 用来返回分页Grid的数据格式
 * Copyright: Copyright (c) 2019
 */
public class PagedGridResult {
    private int page;            // 当前页数
    private long total;            // 总页数
    private long records;        // 总记录数
    private List<?> rows;        // 每行显示的内容
    ...
    get/set
    ...
}

AdminUserServiceImpl 中 分页查询：queryAdminList 方法

相比于之前，我们这没啥查询条件，所以 criteria 这个条件介质我们就不要了。
针对 example 可以增加一个额外属性：ordeby 这个可以根据某一个属性进行排序。这里就用创建时间了.
这个返回了一个List，这是查询分页.

@Override
    public PagedGridResult queryAdminList(Integer page, Integer pageSize) {
        Example adminExample = new Example(AdminUser.class);
        adminExample.orderBy("createdTime").desc();    //用创建时间排序
        PageHelper.startPage(page, pageSize);    //使用分页工具：PageHelper
        List<AdminUser> adminUserList =
                adminUserMapper.selectByExample(adminExample);    //返回查询分页.
        return setterPagedGrid(adminUserList, page);    //上部分封装好的方法.
    }

//接口如下
@ApiOperation(value = "查询admin列表", notes = "查询admin列表", httpMethod = "POST")
@PostMapping("/getAdminList")
public GraceJSONResult getAdminList(
//这里使用了swagger2的注解对两个形参进行解释。这里required表示是否必要，true就表示必要
    @ApiParam(name = "page", value = "查询下一页的第几页", required = false)
    @RequestParam Integer page,
    @ApiParam(name = "pageSize", value = "分页查询每一页显示的条数", required = false)
    @RequestParam Integer pageSize);

拦截器：拦截分页配置插件 PageHelper

service 层方法补充分页拦截器
（1）分页插件使用介绍：使用拦截器
分页其实已经设置好了，是在项目中做了配置.
admin 项目中的 yml 文件打开，里面有一个 pagehelper（啥时候高进来的？？？）.

若想使用插件，搞个拦截器就好。当调用如下框起来的查询时，拦截器会追加分页信息

（2）实现：补充pageHelper的方法（这个类哪个包到进来的？？？？）

§ 5.1.4 admin 账号登出

会话 和 cookie 删掉即可.

（1）redis中删除会话token
（2）coolie中删除admin登陆信息
① 为此，我们专门去写一个deleteCookie方法：BaseController中追加
如下：通过设置cookie存在时间为0的方式来删除cookie
1）cookieValue这里进行encode（？？？？这一步是啥意思？？？？）
encode这里有异常，处理一波
2）存在实际设置为0，只能删除了
② 处理controller

    @Override
    public GraceJSONResult adminLogout(String adminId,
                                       HttpServletRequest request,
                                       HttpServletResponse response) {
        // 从redis中删除admin的会话token
        redis.del(REDIS_ADMIN_TOKEN + ":" + adminId);
        // 从cookie中清理adming登录的相关信息
        deleteCookie(request, response, "atoken");
        deleteCookie(request, response, "aid");
        deleteCookie(request, response, "aname");
        return GraceJSONResult.ok();
    }

public void deleteCookie(HttpServletRequest request,
                             HttpServletResponse response,
                             String cookieName) {
        try {
            String deleteValue = URLEncoder.encode("", "utf-8");    //置空，表示删除.
            //调用 setCookieValue
            setCookieValue(request, response, cookieName, deleteValue, COOKIE_DELETE);
        } catch (UnsupportedEncodingException e) {
            e.printStackTrace();
        }
    }

    public void setCookieValue(HttpServletRequest request,
                          HttpServletResponse response,
                          String cookieName,
                          String cookieValue,
                          Integer maxAge) {
        Cookie cookie = new Cookie(cookieName, cookieValue);
        cookie.setMaxAge(maxAge);
//        cookie.setDomain("imoocnews.com");
        cookie.setDomain(DOMAIN_NAME);
        cookie.setPath("/");
        response.addCookie(cookie);
    }

【重要】疑问：admin登陆不用redis吗？寸的session、token这些怎么用的？前端处理还是后端处理？

seesion token 不是不维护登陆状态用的？一个网站不用进入一个模块就查数据库，而是直接看token就行？
那查看redis的代码在哪呢？（包括第三章）==>在拦截器中呢，拦截器那里判断redis里若是有数据，对比完了直接放行
那redis没有token代表什么？没登陆？还是得去mysql中获取？？？

§ 5.2 MongoDB & GridFS 介绍

MongoDB 介绍

简介

人脸入库需要用到这个。MongoDB 可以存储 JSON。
MongoDB 是非关系型数据库，也就是nosql，存储json数据格式会非常灵活，要比数据库mysql/MariaDB更好，同时也能为 mysql/MariaDB 分摊一部分的流量压力。
对于经常读写的数据他会存入内存，如此一来对于热数据的并发性能是相当高的，从而提升整体的系统效率。另外呢，对于非事务的数据完全可以保存到MongoDB中，这些数据往往也是非核心数据。
一般来说，我们可以把一些非重要数据但是读写却很大的数据存储在MongoDB，比如我们自己的物流运输的车辆运行轨迹，GPS坐标，以及大气监测的一些动态指标等数据。又或者说咱们实战中的友情链接，友情链接在首页，这数据本身不重要，但是在首页里会经常被读到，并发读很大，所以放mongoDB中没毛病。
此外，mongodb 提供的 gridfs 提供小文件存储，可以自己把控接口读取的权限，这一点也是有优势的，比如存储一些身份证信息啊，人脸信息啊都是可以的。

术语

以下是MongoDB和数据库以及ElasticSearch(es没接触过的，待后续整合es后可以回过头来对比看看)的术语对比：

数据结构演示

一个 {} 就是一个大对象 / 一个document / 一个JSON对象.
MongoDB 是 Nosql 数据库，一个 {} 三个结构，另一个可以是四个结构.

• MongoDB可以创建多个数据库（同mysql）
• 一个数据库可以创建多个collection（同mysql创建多表）
• 一个集合可以包含很多文档数据（同mysql一张表包含很多行记录）

我们可以通过如下代码片段来更好的理解MongoDB的数据对比，假设这张表中总记录有3条

UserList: [
    {
        userId: "1001",
        username: "lee",
        age: 18,
        sex: "boy"    
    },
    {
        userId: "1002",
        username: "jay",
        age: 20,
        sex: "boy"    
    },
    {
        userId: "1003",
        username: "jolin",
        age: 19,
        sex: "girl"    
    }
]

如上述代码中：

• UserList是一个collection，在mysql中可以当做是一张表
• UserList中的每个{}都是一个json对象，他们称之为document文档，在mysql中称之为行记录
• userId、username、age、sex 这些都是field 域，在MySQL中称之为column列字段

GridFS

一、介绍

一般软件中，bucket相关的都是和“文件存储”挂钩.
为了实现人脸识别，我们需要用到gridFs Buckets这个模块.
这个也算是一个“对象”，我们需要将其放到spring容器中去，随后才能使用它进行文件的上传，传到 mongodb 中去.

二、整合 SpringBoot

1 定义接口

file 工程中的文件上传 controller 的 api 中：这样的话，前端那里手机号图像，点击确定后，就会触发这里的方法.
==>【其实不仅仅可以上传人脸文件，其他文件都可以通过这个方法上传】！！！

2 引入依赖

…

3 mogodb配置信息

打开当前项目的 yml 文件：
spring的下面加：

这里数据库这个imooc-news数据库中没有，得先去创建一下.

4 编写 GridFS 配置类

file包下搞一个配置类.
str 这个 mongodb 就是获取配置文件中 mongodb 信息的。gridFS Bucket 这个方法就是我们之前引入以后才可以调用的；其他一些没见过的形参基本也都是输入mongodb的依赖的.

————————
至此，mogodb 和 gridfs 就算是整合到项目中去了.

§ 5.3.1 人脸入库

流程

入库

Chrome开启视频调试模式

实现人脸存入MongoDB 【GridFS】

人脸入库，我们会把用户的人脸信息保存到 gridfs 中，当然如果使用oss或者fastdfs也可以，只不过gridfs可以控制在内部访问，其他的相对不是很方便，而且做好内部资源和外部资源的解耦也是一种不错的选型。（？？？不是很懂，什么内部资源外部资源的？？？）
接下来，我们就需要去实现我们写的 api 中的文件上传至 GridFS 的方法了。

前端拿到 文件ID 以后，会在下次提交时把这个 id 提交到后端，这样的话，【mongodb 就和 Mysql 建立了关联】.

思考：mysql 和 mongodb 怎么建立联系的 ？？？
==> 注意，mongodb 只存了 用户文件 的 fileId 和 头像 img64，所以注定了若想查询这里的数据，都必须是【根据用户 id，去 mysql 中拿到 fileId，然后用fileId 去 MongoDB 中查询头像】.

@Override
    public GraceJSONResult uploadToGridFS(NewAdminBO newAdminBO)
            throws Exception {
        // ① 通过 bo 获得 base64 的字符串
        String file64 = newAdminBO.getImg64();
        // ② 通过decodeBuffer把这个字符串转成byte数组，中间使用trim去除两边的空格
        byte[] bytes = new BASE64Decoder().decodeBuffer(file64.trim());
        // ③ byte[] 就可以转成输入流
        ByteArrayInputStream inputStream = new ByteArrayInputStream(bytes);
        // ④ 上传成功以后，我们通过 fileId 拿到其再 gridfs 中的 id，这个就可以返回给前端了。   
        // 上传到gridfs中，需要注入 gridFSBucket 这个类.
        ObjectId fileId = 
            gridFSBucket.uploadFromStream(newAdminBO.getUsername() + ".png", inputStream);
        // 获得文件在 gridfs 中的主键 fileId
        String fileIdStr = fileId.toString();
        return GraceJSONResult.ok(fileIdStr);
    }

查看admin人脸信息【GridFS】（人脸登录模块要调用）

分析：需要建立起 mysql 的 id 和 mongodb 的 faceId 的联系

目前实现了：人脸入 mongodb 库 。admin 列表中，可以点击查看人脸，如果有人脸的话，就可以显示了。目前点开还是什么都没有. 本节课就实现这个.
我们点击人脸，有一个参数的传递，点击的时候拿到了数据库的【 admin表 的 faceId】 ，传给后端。后端接收到这个id，我们【去 mongodb 获得这个文件】，然后传给前端输出即可.（和咱之前分析的逻辑一致）

readGridFSByFaceId：从mongoDB获得文件，保存一个temp文件，然后下载到本地

（1）（2）
mongodb中，ID 才是主键，实际上调用时候得用 _id；
find 方法返回值是一个列表，所以结果用 GridFSFindIterable（不是，都说了主键是唯一的，为什么还能查出来多个值？？？是这个意思吗？）
==> 这个find 可以查各个字段的吧，只不过 id 这个比较特殊，虽然查出来是列表，但是必然就 1 个元素。同时，也正因为就 1 行数据，那么就可以调用 first 方法，第一个必然就是结果了，当然，也就只有这 1 个数据。

（4）
拿到 文件 以及 文件名 就可以输出了，我们其实可以把当前这个文件在服务器上进行保存，然后写到临时目录（？？？什么现在本地，linux的话就临时目录啥的？？？），然后可以通过 response 展现给前端。所以，file 这里我们就把目录写死了；可以判断一下这个目录有没有，如果没有的话就创建这个目录.
==> 我们一般做法都会在机子上留存temp文件，方便排查问题。定时删除就行的哈。
（7）
return 的是个 file，这个 file 在 new 的时候制定了 “文件路径” + “fileName”，这样的话，直接能跟着这个找到我们存储的文件了？是这个意思吗？？

（….说实话，这一段好多血继不懂，那个gridFS不是文件吗？咋最后除了得个名字也没见用到呢？还是说之前那个gridFS只是获得文件名，最后文件的落地还是得靠这个gridFSBucket调用过的download方法吗？？？）

//【核心】查询的时候就和 数据库传过来的 faceId 进行匹配.
private File readGridFSByFaceId(String faceId) throws Exception {
    //（1）这里调用 mongodb 包里面的 filters 类进行过滤查询，这个就是和mongodb里机制一样.
        GridFSFindIterable gridFSFiles
                = gridFSBucket.find(Filters.eq("_id", new ObjectId(faceId)));
    //（2）通过first文件保证得到第一个，返回一个文件类；    
    GridFSFile gridFS = gridFSFiles.first();
    //（3） 再判空一下，不空时，拿到文件.
    if (gridFS == null) {
            GraceException.display(ResponseStatusEnum.FILE_NOT_EXIST_ERROR);
        }
        // 我们先或得一下filename，为了方便测试，我们这里先写一个sout；
        String fileName = gridFS.getFilename();
        System.out.println(fileName);
        // （4）获取文件流，保存文件到本地或者服务器的临时目录
        File fileTemp = new File("/workspace/temp_face");
        if (!fileTemp.exists()) {
            fileTemp.mkdirs();
        }
        File myFile = new File("/workspace/temp_face/" + fileName);
        // （5）创建文件输出流
        OutputStream os = new FileOutputStream(myFile);
        // （6）下载到服务器或者本地
        gridFSBucket.downloadToStream(new ObjectId(faceId), os);
        // （7）    
        return myFile;
    }

readInGridFS ：从gridfs中读取文件，然后输出给浏览器

刚才写的方法返回了一个file，接受一下.
然年后把图片输出到浏览器即可，这里需要用到一个工具类：FileUtils。包含了两个方法：下载文件 和 输出成base64。我们用的就是这个下载文件这个方法，这个方法就是把图片搞到了response中。因为需要用到response，我们去api中补充一下形参.

    @Override
    public void readInGridFS(String faceId,
                                        HttpServletRequest request,
                                        HttpServletResponse response) throws Exception {
        // 0. 判断参数
        if (StringUtils.isBlank(faceId) || faceId.equalsIgnoreCase("null")) {
            GraceException.display(ResponseStatusEnum.FILE_NOT_EXIST_ERROR);
        }
        // 1. 从gridfs中读取
        File adminFace = readGridFSByFaceId(faceId); //该方法见下面
        // 2. 把人脸图片输出到浏览器
        FileUtils.downloadFileByStream(response, adminFace);
    }