黑马点评项目总结

心已赠人 2024-03-26 14:10 119阅读 0赞

#### 点评项目总结 ####

*  整体架构
 *  一. 短信登录模块
 *   *  1.1 基于session
     *   *  （1）后台发送验证码Code
         *  （2）登录、注册
         *  （3）校验登录状态
     *  1.2 基于Redis
     *   *  （1）后台发送验证码Code
         *  （2）登录、注册
         *  （3）校验登录状态（更新Token有效时间）
     *  1.3 补充
 *  二. 商户缓存模块
 *   *  2.1 基本查询流程（缓存模型实现）
     *  2.2 缓存一致性（三点保证）
     *  2.3 缓存穿透、缓存雪崩、缓存击穿
 *  三. 优惠券秒杀
 *   *  3.1 全局唯一ID
     *  3.2 实现优惠券秒杀（基本）
     *  3.3 乐观锁解决“超卖问题”(多扣库存)
     *  3.4 实现“一人一单”(一人下了多单)
     *   *  3.4.1 单线程时
         *  3.4.2 Synchronized 悲观锁的问题 ※
         *  3.4.3 Redis分布锁实现一人一单（初级）
         *   *  （1）分布式锁的实现
             *  （2）分布式锁实现“一人一单” ★
         *  3.4.4 Redis分布锁“误删”问题 ★ ★ ★
         *  3.4.5 Redission分布锁实现一人一单 ★ ★ ★
         *  3.4.6 Redission分布式锁总结+联锁
         *  3.4. Redis秒杀优化
         *   *  （1）优化思路
             *  （2）实现：主线程秒杀
             *  （3）实现：异步线程下单
 *  四. 达人探店
 *   *  4.1 发布笔记（保存）
     *  4.2 查看笔记（返回blog对象+作者信息）
     *  4.3 实现点赞功能
     *   *  需求一：
         *  需求二：

## 整体架构 ##

![在这里插入图片描述][8b42d360835a4203a47be39f5c9da7f6.png]

## 一. 短信登录模块 ##

### 1.1 基于session ###

#### （1）后台发送验证码Code ####

1.  前端提交手机号获取验证码（参数为手机号String和HttpSession）
2.  后台检验手机号是否合法（`RegexUtils`工具类），不合法就返回错误信息
3.  合法就用`RandUtil`工具类随机生成验证码吗，并将验证码setAttribute保存到 **`session`** 中，用于第二个环节的验证；
4.  向用户发送验证码（这里 `log.debug`(xxx)写到日志模拟）；  
    ![在这里插入图片描述][eef4b7ea8ce0414b8888cea837f13ffd.png]![在这里插入图片描述][4d2f799365b44c4995b9f32e7a500075.png]

@RequestParam：GET请求，url传参，表单传参；

#### （2）登录、注册 ####

1.  用户提交手机号和验证码
2.  后台再次验证手机号是否合法（两次请求，都要验证），如果不合法就报错
3.  取出 **`session`** 中的验证码Code，和用户传的Code对比是否正确，不一样则报错；
4.  正确则：通过手机号从数据库User表查询User对象，  
    判断：如果User为空就用Mybatis添加数据库（注册：创建User对象、set手机号、set随机用户名）；
5.  不管有没有user，最后都把user对象保存 **`session`** 中，用于保存登录状态用于后续登录校验；  
    ![在这里插入图片描述][9fc4e91947654c4eb83bde155d01b579.png]

#### （3）校验登录状态 ####

用户点提交后，会跳转到用户详情页，此时前端会向 /user/me 发起请求 ，请求对应的controller的me()方法要返回一个User对象供前端展示，但是这是新的请求，而只有登录了的用户才能访问这个方法；  
为了统一去对需要登陆才能访问的页面进行登录校验，以及过滤不需要登录就可以访问的页面，使用`拦截器`进行校验登录状态，  
则每一个请求在到达controller的方法之前都需要经过拦截器！

1.  定义一个**拦截器类**，实现`HandlerInterceptor`接口，重写`preHandle`方法；  
    然后在SpringMvcConfig中配置拦截器，重写`addIntercepter()`排除不需要登录就能访问的地址；
2.  在拦截器的`preHandle`方法中，从 `request`获取session对象，再从session对象获取user对象（session被Tomcat自动维护，一个浏览器对应一个session）
3.  判断：  
    ①如果user对象不存在则表明没有通过第二个环节登录成功，返回报错401(未授权)，return false；  
    ②如果user对象存在则说明登陆过了，此时需要返回user对象给前端展示，这里为了controller快速读取用户信息，一方面为了安全性，就把user对象存入 `Threadlocal`，后序用户从ThreadLocal直接读取信息更安全；
4.  preHandle方法return `true` 放行请求，  
    请求会到达controller的me()方法，该方法会从`ThreadLocal`中获取user对象，供前端展示到用户信息页面；
5.  在`postComplition`中remove移除ThreadLocal中的用户信息；

拦截器类：  
![在这里插入图片描述][a6427eca7b824680ac4e47fd4b32bc47.png]

配置拦截器：  
![在这里插入图片描述][f6d4ad7415dd49a2bfa590d9e9ec4d77.png]

使用Session来完成登录时，登录凭证就是sessionID，Tomcat服务器会自动维护SessionID；

以上就是使用session、拦截器、ThreadLocal实现的用户登录和校验的过程；  
**问题**：  
当Tocmat服务器扩张成一个服务器集群，而不同的Tomcat是不同的JVM内存，不能共享session；  
当浏览器发送请求到 **Nginx**，由Nginx进行 **负载均衡** 时，同一个浏览器的不同请求就可能发往不同的Tomcat服务器，这样数据读取就出问题；

**解决**：  
Tomcat使用session互相拷贝；  
①多台服务器拷贝浪费空间 ②拷贝需要时间，有延迟（服务器是进程，进程通信效率低）

所以使用Redis充当 **`缓存服务器`** 专门用来存数据，让Tomcat都可以去访问，实现数据的共享；

### 1.2 基于Redis ###

#### （1）后台发送验证码Code ####

1.  客户端提交手机号
2.  后台检验手机号是否合法，不合法就返回错误信息
3.  合法就用工具类随机生成验证码吗，使用`StringRedisTemplate.opsForValue()`将验证码作为`value`保存到 **`Redis`** 中，`key`就是手机号，用于第二个环节的验证；
4.  向用户发送验证码；  
    ![在这里插入图片描述][e19c6c7a0a474f8c9f08467ac63500c0.png]

**Redis中存的第一类数据**（验证码）：**`key`** 为手机号+“前缀”（保证唯一性），**`value`** 就是验证码；

#### （2）登录、注册 ####

1.  用户提交手机号和验证码
2.  后台再次验证手机号是否合法（两次请求，都要验证），如果不合法就报错
3.  用手机号作为key去GET`Redis`中对应的验证码Code，和用户提交的Code对比，不一样则返回错误；
4.  一致则通过手机号从数据库查询User对象，如果User为空就用Mybatis添加数据库（注册）；
5.  不管有没有user，都需要将user对象存到 Redis中(之前是存到session，session是Object可以存任意类型)；  
    `value`：此时用`BeanUtil`工具类把User对象转换为`Map`作为value，这样就能放到Redis中了；（String存json也可以）  
    `key`：key则使用UUID工具类产生token随机字符串（登录凭证）；  
    最后`StringRedisTemplate.opsForHash().putAll()`把user对象存入 **`Redis`**；
6.  使用`StringRedisTemplate.expire()` 方法设置Token的有效时间；
7.  由于此时Token是登陆凭证，将登陆凭证`Token` 返回给前端，前端执行sessionStroger()将其存到浏览器中，以后每次访问都放在【请求头】中；  
    ![在这里插入图片描述][dd4dcc03bcee47eaaeac9b92279fba26.png]  
    ![在这里插入图片描述][1e65ca0f3a194c5a9c1d8e81c86e6ad5.png]

前端会用一个`sessionStorage()` 将Token存到浏览器中，以后每次访问都在【**请求头**】中带着Token；

#### （3）校验登录状态（更新Token有效时间） ####

用户点击提交之后，会跳转 */user/me* 用户详情页面，向controller发起请求，controller中对应的方法会返回一个User对象，但是需要登陆过的用户才能去访问这个方法；  
为了统一去对需要登陆才能访问的页面进行登录校验，以及过滤不需要登录就可以访问的页面，使用`拦截器`进行校验登录状态；

1.  定义一个拦截器类，实现`HandlerInterceptor`接口，重写`preHandle`方法；  
    然后在SpringMvcConfig中配置拦截器，排除不需要被拦截的地址；
2.  在拦截器的`preHandle`方法中，调用`request`中 getHeader() 读取【**请求头**】中的 **`Token`**，如果不存即第二个环节没通过，返回错误401(未授权)；
3.  以Token为key，从Redis中取出user的**Map**，  
    ①如果Map不存在，也返回错误401，return false；  
    ②存在应该放行，放行之前，使用`BeanUtil` 将Map转换为User对象，存入 **`Threadlocal`**（方便和安全性）；
4.  用`StringRedisTemplate.expire()` 更新Token（key）的有效期；（刷新登录状态）
5.  return true 放行请求，访问个人信息页面；

![在这里插入图片描述][1472ba77691549f19571ff77ddd1b044.png]![在这里插入图片描述][5263eaed2d714148b0ebbd17fc439f8a.png]![在这里插入图片描述][54bc449e8ba44bf8a9e9dda206ea76d0.png]

注意Redis存的是两类数据，一个是 手机号–Code ，另一个是Token–User  
![在这里插入图片描述][0ffbb31a1607454d9885c498cf3cb03b.png]

### 1.3 补充 ###

**问题：用户登录状态的保持主要靠的是拦截器中更新Token有效时间，但是访问 shop店铺、blog博客时没有更新Tokend有效时间 ！**

**解决：再增加一个拦截器 ！**  
让第一个拦截器对所有请求操作，获取Token，保存User用户到ThreadLocal  
第二个拦截器来实现拦截功能；

1.  **第一个拦截器**：（对所有请求页面拦截）  
    如果发现Token为空，则直接return true放行到第二个拦截器；  
    通过Token获取User，不存在则放行，  
    将User存储放在第一个拦截器；
2.  **第二个拦截器**：（对部分请求页面拦截）  
    判断ThreadLocal中是否有用户，没有则拦截，有则放行；

**配置拦截器**：  
通过设置拦截器的 **`order`**，来控制拦截器的执行顺序！  
oder越小，优先级越高；

第一个拦截器：  
![在这里插入图片描述][b79698511ecc44d0acfb54476f8ce043.png]

第二个拦截器：  
![在这里插入图片描述][414f31e24e13471a8ca4a744cfe35036.png]  
配置拦截器：  
![在这里插入图片描述][f4108e4a070c417d8629788797dbf9f1.png]

Redis：

1.  存储验证码，用于登录时验证；
2.  存储User对象，用来保存用户的登录状态；

## 二. 商户缓存模块 ##

**引入**：当前端发来大量请求时，如果都去查询数据库则会导致其崩溃，同时为了提高响应速度（基于内存），所以让Redis作为**缓存型数据库**；

**缓存工作模型**：  
在【客户端和数据库】之间添加了一个中间层！  
这样客户端请求会优先到达缓存Redis！  
如果Redis中有数据就返回，就不用走数据库了（请求命中）；  
若没有才去查询数据库（未命中），然后把数据更新到缓存，这样下一次再查询就可以使用缓存了；  
随着用户请求越多，Redis中缓存的数据越多，Redis的命中率就会越来越高；  
![在这里插入图片描述][64030218ab534e45998f9a769c620be0.png]

### 2.1 基本查询流程（缓存模型实现） ###

**查询流程：**  
`key`：店铺id  
`value`：店铺信息Json

1.  注入stringRedisTemplate的bean，  
    前端提交店铺id请求，后端通过id(key)从Redis GET查询 商户缓存，如果命中则返回商铺信息；  
    这里存商铺信息value的是String格式，则需要将String格式的Json 用`JSONUtil`工具类反序列化为Java对象；
2.  未命中则，查询数据库中的商铺表，若不存在，报错；
3.  若数据库中存在，则用stringRedisTemplate.opsForVlaue将商铺对象序列化，再更新Redis中，下次再查就可以命中了；
4.  再把商铺对象返回；  
    ![在这里插入图片描述][f337db91213b4fb59b97414308b5757f.png]

### 2.2 缓存一致性（三点保证） ###

[缓存一致性][Link 1]

### 2.3 缓存穿透、缓存雪崩、缓存击穿 ###

[缓存穿透、缓存雪崩、缓存击穿][Link 2]

## 三. 优惠券秒杀 ##

### 3.1 全局唯一ID ###

**引入**：分布式场景下，数据库AUTO\_INCREMENT自增ID性能有效，

[全局唯一ID][ID]

### 3.2 实现优惠券秒杀（基本） ###

项目中的商铺就是优惠券；

有两种优惠券： 普通券(不需要秒杀) 、**秒杀券**；  
所以秒杀是针对秒杀券；

**秒杀券**：  
注意有timestamp类型的有效时间字段；  
![在这里插入图片描述][65584889249d431d89d3296ff58575aa.png]

**流程：**  
商铺是优惠券，主要字段：id、有效时间、库存；  
需要注入 秒杀券service的bean，和生成全局ID的redisIdWorker的bean；

1.  前端提交秒杀券ID，根据ID获取秒杀券对象；
2.  **判断时间** 是否正确，当前时间早于和晚于秒杀券的有效时间都返回错误；
3.  **判断库存** 是否充足；  
    ①如果秒杀券中库存不足，则返回错误；  
    ②如果秒杀券中库存充足，则对秒杀表 **扣库存**`(超卖安全问题)`，
4.  在订单表中 **创建订单对象**（**全局唯一**的订单id、秒杀券id、用户id）存入订单表；
5.  返回订单ID

![在这里插入图片描述][b57c85bb70d845b6be6deb93e1059c03.png]  
![在这里插入图片描述][eb773fef8aec4664ac77690c7d1b285f.png]![在这里插入图片描述][d4ee8c0c4d7a4473a367c70f66bbe246.png]  
![在这里插入图片描述][1cd773dbeb79447d9a92075392dd3a6d.png]

### 3.3 乐观锁解决“超卖问题”(多扣库存) ###

**超卖问题：**  
当库存还剩余1时，多个线程都去查询库存，剩余1即可以扣库存，然后多个线程都去扣库存，库存被扣为负数，就出现了 **`超卖现象`** ！

**解决方案**：  
悲观锁：线程同步串行执行，效率低，不适合高并发场景；  
乐观锁：CAS，在线程对数据更新时才做判断，判断在当前线程之前有没有其他线程对数据有修改；

**思路**：在【扣库存】的时候，当前库存与之前查询到的库存是否相同，是则可以修改，否则不修改；  
因为库存是在变化的，适合使用乐观锁；  
![在这里插入图片描述][faa069ccc0b44a8197b446a6c7418b15.png]  
**结果**：异常比例高达89% ！

**原因**：当有一个线程成功，则其他的线程由于stock改变了就都更改失败了！ 没有自旋；

**改进**：改为 `where stock>0` 即可；因为**DML**语句默认有 **`行锁`**，在修改时会加上行锁，避免线程安全问题；

### 3.4 实现“一人一单”(一人下了多单) ###

**需求**：要求同一个用户只能下一单！（避免黄牛）

**思路**：`用户ID`和`秒杀券ID`有唯一性，即判断用户ID和秒杀券ID已经同时存在，则不能再下单；

#### 3.4.1 单线程时 ####

**流程**：  
在满足秒杀券有效时间和库存后，**【查询库存后】【扣库存之前】** 要做`用户ID`和`秒杀券ID`的 **联合查询**，  
①如果联合查询结果>0 存在则返回异常；  
②如果联合查询结果=0即不存在，则扣库存，生成订单对象，存入订单数据；  
![在这里插入图片描述][367bd51509634acaa03f68f8d9b58bbc.png]  
**问题**：  
由于多个线程并发执行，下单时多个线程用同一个用户ID访问，则会下多个订单；  
![在这里插入图片描述][84af3dbce14043e8ba6190d0d172366e.png]

#### 3.4.2 Synchronized 悲观锁的问题 ※ ####

**需求**：使用悲观锁主要是防止同一个用户下多个订单！

之前是用**扣库存**是用乐观锁，因为库存是在变化的，通过判断stock值是否变化就可以实现乐观锁；  
而这里是涉及**下单**，是向订单表**新增**，没法判断某个值是否变化，所以用悲观锁！

**synchronized加到哪？**  
【查询库存后】，从联合查询、扣减库存、到创建订单 这个过程加上悲观锁！  
将这三个步骤提取为一个`createVoucherOrder`方法；  
事务是为了保证减库存和创建订单，可以把`@transactional` 放到createVoucherOrder方法上；

![在这里插入图片描述][c0d1d9f8d9524eb38d4d906d7f6f5c7a.png]  
![在这里插入图片描述][7177062cf4ab4eee9ea96b6a061c1a6b.png]

如果synchronized加到方法上，则共享对象是this，是串行执行，效率低；  
而线程安全问题主要是同一个用户ID引起，所以锁的应该是同一个用户ID的情况，则 **锁定的共享对象为用户ID**；  
由于toString()方法底层还是new了一个String，不同String会被判定为不同，所以调用 intern()方法（池化，尝试将字符串放入串池，如果已经有了就返回串池中的对象）；这样能保证用户ID一致时锁就一样；锁定范围变小，性能更好；  
锁应该在事务提交之后再释放！假设synchronized在方法内，则可能锁释放了但事务还没有提交，所以将synchronized放在整个方法之外！ ※  
当createVoucherOrder方法执行完则事务已经提交 ，再释放锁，就不会有线程安全问题了；  
![在这里插入图片描述][619b13511a904615a66c20375a0b17d4.png]

Spring事务的本质是通过动态代理，而此时使用 return createVoucherOrder方法相当于使用事务的方法是由this调用的，就不是动态代理的，Spring事务会失效！  
需要通过AopContext.currentProxy()拿到当前对象（VoucherOrderServiceImpl）的代理对象！  
![在这里插入图片描述][88f7fb96b17743b3af20f5318049269a.png]

还需要在类上  
①添加aspectjweaver的依赖；  
②在启动类中添加注解暴露代理对象  
![在这里插入图片描述][ae9c4cc0f89e46389f3282b2c39eaa34.png]

#### 3.4.3 Redis分布锁实现一人一单（初级） ####

**Synchronized锁的问题：**  
只适用于单个Web服务器使用；  
在Web服务器为集群的情况下，则 **锁失败，锁不住**！

**原因**：  
不同的Web服务器→不同的进程、即不同的JVM→不同的字符串对象（`userID`）→不同的Monitor对象→不是同一把锁；

**分布式锁引入**：  
因为Synchronized只能保证单个JVM内部的多个线程的互斥，而多个JVM进程之间无法生效；

##### （1）分布式锁的实现 #####

**`SETNX`** \+ **`EXPIRE`**  
`key`：锁的名称在实现类中被传入  
`value`：锁的值使用线程ID  
**①定义一个锁接口**  
![在这里插入图片描述][302a026bdd494185a0c92c3dc00a31bc.png]

**②实现类实现ILock**  
锁的key为name属性；  
![在这里插入图片描述][3e3e97c4efcf4f7dbca2248e768a7d3e.png]  
重写tryLock方法：  
传入  
![在这里插入图片描述][20f6f8b29bd148f39c7fb1453650553d.png]  
`key`由外部传入；  
而`value`使用线程的标识，所以使用Thread.currentThread()； getId获取线程的ID，不会重复；  
返回值是Boolean包装类，这里为了防止空指针，使用Boolean.TRUE.equals去比较，如果false和null都会返回false；

释放锁：  
![在这里插入图片描述][6c790eb716af424896e807b0edca5343.png]

##### （2）分布式锁实现“一人一单” ★ #####

1.前端提交优惠券ID，在service中查询秒杀券信息（时间、库存）  
2.判断时间是否正确；  
3.判断秒杀表中的库存是否充足；  
①如果库存不足，则返回错误；  
②如果库存充足：

*  **创建锁**，输入 **`用户ID`** 作为 **`key`** ！这样就实现一个用户只有一把锁！实现一个一单； 并输入锁的超时时间；
 *  尝试获取锁，成功 则执行`createVoucherOrder`方法：  
    扣库存；  
    在订单表中创建订单（订单id、代金券id、用户id）；  
    返回订单ID；
 *  释放锁

![在这里插入图片描述][f983eece56d3449ab647781ef623f7f1.png]

#### 3.4.4 Redis分布锁“误删”问题 ★ ★ ★ ####

**（1）初级版本**：  
**上锁时**：使用`SETNX`\+`EXPIRE`；  
`key`为用户ID保证一个用户一把锁，不同用户之间不阻塞，`value`为`线程标识`（UUID+线程ID）  
**解锁时**：先判断当前线程标识和锁的线程标识是否一致，一致才释放，不一致则不释放，防止误删；

**UUID**：  
1.`static`静态修饰，保证一个服务器对应一个UUID；  
2.为了防止不同服务器的线程ID重复；

**（2）改进版本**  
[解决误删问题][Link 3]  
**问题**：由于释放锁的时候判断锁和释放锁是两个操作，不具有原子性，所以还是可能导致锁误删；  
**解决**：  
把判断线程标识和释放锁放到同一个Lua脚本中，然后在使用锁时用`execute()`执行脚本，保证了原子性；

#### 3.4.5 Redission分布锁实现一人一单 ★ ★ ★ ####

注入bean：  
![在这里插入图片描述][06b38c3b20524eaa9a85de1abe28e21a.png]  
上锁→执行createVoucherOrder(联合查询、扣库存、创建订单)→释放锁；  
![在这里插入图片描述][7df1fd9cfbf745f7959fe3a1685423d3.png]

#### 3.4.6 Redission分布式锁总结+联锁 ####

1.  **可重入**：基于Hash结构，使用Hash的`value`来记录锁重入的次数（类似Reentrantlock）
2.  **可重试**：借助发布订阅模式，第一次尝试失败以后不会立即失败，而是会等待释放锁的消息，而获取锁成功的线程在释放的时候会发送消息，则等待的线程捕获到消息会再次尝试获取锁；如果再失败，则继续等待释放锁的信号，捕获信号后再次尝试获取锁；超过持续时间就不再重试；
3.  **超时续约**：利用`watchDog`看门狗，获取锁成功后会开启一个`定时任务`，这个任务每隔一段时间就去重置锁的超时时间！避免锁因为业务阻塞而被删除；
4.  **主从一致性**：使用 **`MultiLock联锁`**  
    不要主从模式，节点都是独立的读写；  
    之前客户端获取锁只需要找到Master节点，而现在需要依次向多个Redis节点都去获取锁，都要保存锁的标识；  
    假设有节点宕机，因为锁依然存在，所以锁依然有效；  
    ![在这里插入图片描述][9e4e496ac9b341e7a2b6cdf2e7b4d6a5.png]

之前客户端获取锁只需要找到Master节点，而现在需要依次向多个Redis节点都去获取锁，都要保存锁的标识，全部获取才能成功；  
假设有节点宕机，因为锁依然存在，所以锁依然有效；

#### 3.4. Redis秒杀优化 ####

##### （1）优化思路 #####

**引入**：  
Web服务器中执行的整个步骤是串行的，而查询数据库速度慢，且有分布式锁，导致性能差；

**思路**：  
将秒杀任务分成两部分交给两个线程去做：

1.  **主线程**(秒杀)：先判断秒杀资格：判断（有效时间省略）、库存是否充足 ，然后查询用户ID是否买过（联合查询）保证一人一单（Redis读操作耗时短 ）；
2.  **异步线程**(下单)：减库存\+创建订单，（数据库写操作耗时长）；

**优点**：

1.  缩短秒杀业务的流程，让主线程秒杀，异步线程去扣减库存和创建订单
2.  减轻数据库的压力

**准备**：  
由于要查询数据库，所以将`秒杀券`和`订单信息`缓存到Redis；  
Redis存秒杀券库存：用String类型，`key`是秒杀券ID，`value`是库存数量；  
Redis存秒杀券ID和用户ID：一个秒杀券有多个库存，所以一个秒杀券ID会对应多个用户ID，且要保证一人一单，`key`是秒杀券ID，`value`是用户ID的集合Set，即一个秒杀券ID的用户中不能重复！所以使用Set；  
![在这里插入图片描述][cd993c532fb14a9a9ba63bef16a17408.png]

**流程**  
Lua脚本（原子性）：

1.  先判断库存是否充足，不足则retuern 1结束；
2.  充足则再判断秒杀券ID对应的用户ID的set中是否存在当前用户ID（相当于联合查询），已存在则return 2；
3.  如果都满足，①则在Redis中预扣减库存；②将用户ID存入set中；
4.  return 0表示有下单资格；

根据Lua脚本返回的结果来处理：

1.  如果返回0即有下单资格，则将秒杀券ID、用户ID、订单ID存入 `阻塞队列`，并返回订单ID给用户，此时秒杀已经结束，  
    扣库存创建订单由 **`异步线程`** 去完成，此时时效性要求并不高；
2.  如果Lua脚本返回1/2则返回错误信息；  
    ![在这里插入图片描述][fd60973c7acf4b8cb8e2079336af768b.png]

##### （2）实现：主线程秒杀 #####

**需求**：  
1.新增秒杀券时，将优惠券信息保存到Redis中（缓存模型）；（用户ID信息是在秒杀的过程中添加的！）  
2.基于Lua脚本，①判断秒杀券的库存、②查询一人一单，决定用户是否有下单资格，有则预扣库存，用户ID存入set；  
3.如果抢购成功，将优惠券ID、用户ID和订单ID存入阻塞队列；  
4.开启线程任务，不断从阻塞队列获取信息，实现异步下单

1.  Lua脚本：  
    ①先判断库存是否充足，通过秒杀券ID取出库存数量判断是否<0（String要转换为数字）；  
    ②然后判断该优惠券ID对应的用户set中是否有当前用户ID；  
    用`SISMEMBER`判断当前oderKey对应的Set中是否存在 用户ID，返回1即存在；  
    ③Set中不存在用户ID则可以去预扣库存，用`INCRBY`命令，向订单orderKey对应的Set去存入用户ID，用SADD；  
    ④成功秒杀则直接向消息队列发送消息  
    ![在这里插入图片描述][757060c96e3a4d108814f00fc97d204a.png]  
    ![在这里插入图片描述][743606cb253f47dc98ae00b1fbc53b96.png]
2.  用`DefualRedisScript`类和静态代码块预先读取脚本  
    ![在这里插入图片描述][897b09a8fe64494fbf5ed9c5ab1dbdc7.png]
3.  `execute()`执行Lua脚本  
    Lua的参数是秒杀券ID和用户ID；  
    ![在这里插入图片描述][f331de63500f4e778a3a1a6da724f7a7.png]

如果返回为0则下单成功，生成全局唯一ID，并将信息传到阻塞队列：

测试：1000个线程  
之前：  
![在这里插入图片描述][5a127afe39fe48dba7ee8a8d3c8bc5df.png]  
优化后：  
![在这里插入图片描述][6f2e86b990ba4c94a31d597cad108210.png]

##### （3）实现：异步线程下单 #####

1.**创建线程池**：实际下单处理不需要很高的时效性，所以创建一个单个核心线程的线池；

2.**线程池自动提交任务**：要让任务在当前类初始化之后就执行，因为项目一启动，用户随时都可以去抢购，所以使用 @PostConstruct 让任务在类初始化后就执行；  
![在这里插入图片描述][6217f4852b734af59ed7228e105fcb7b.png]  
3.**Runnable任务**：  
①获取Stream消息队列中的订单消息，没有消息则阻塞2秒  
②判断消息获取是否成功  
如果失败则继续下一次循环读取  
③如果成功则解析list，转成Voucher对象，执行下单；  
④ACK确认；  
![在这里插入图片描述][a9e2c8064f874e33b7d7ef5f4609ddfd.png]  
![在这里插入图片描述][cef0a1d612954ef7b0e3e727b9f76e07.png]

**`异常`则执行handlePendingList**：（当出现异常时，消息没有做ack确认，所以消息依然在appeding-list中，这时使用起始ID使用0 ）  
此时读的不是消息队列而是 pending-list，所以是 标识为0；  
如果消息获取失败，说明pending-list中没有异常消息，则结束循环；  
有则取出数据去下单；  
![在这里插入图片描述][9735015eab5b470da37bb51a2a8ee7f1.png]

**整体流程：**  
1.尝试从消息队列中读取消息，没有则continue，下一轮循环  
2.如果有消息则提取信息，传入handleVoucherOrder去下单；  
3.ACK确认；  
如果抛出异常导致没有ACK确认，则执行handlePendingList：  
1.从pendingList中读取，起始ID为0，  
2.读到则解析消息，下单  
3.如果异常消息处理完了即返回的list不存在，则break；  
4.如果过程中再抛异常，则继续循环即可，知道pending-list返回的list不存在即异常都处理完成就break；

**回顾秒杀中Redis做了什么？**  
1.一人一单的线程安全问题用了SETNX锁、redission锁；  
2.将同步秒杀变成异步，用redis存储库存和订单信息，再Lua脚本完成秒杀资格判断；而后把下单任务放到阻塞队列中  
3.将阻塞队列优化成消息队列；

## 四. 达人探店 ##

### 4.1 发布笔记（保存） ###

**(1) UploadController 上传图片**（“upload/bolg”）：  
1.前端以post的方式上传照片到controller，@requestParam即普通参数；  
2.传入图片的参数类型为`MultipartFile`，继承自InputStreamSource，使用MultipartFile的`transferTo()`方法保存图片到Nginx，并返回图片的`url`；  
一般企业会把图片会放在图片服务器，这里简化为保存到Nginx中，将来前端才能访问；  
![在这里插入图片描述][285b55bc93cb4b12a572668acc9a2713.png]  
@RestController= responseBody+Controller  
@RequesMapping即urlPattern  
@RequestParam即普通参数类型

**(2) BlogController保存笔记**（“blog”）：  
1.前端将店铺ID、图片地址、笔记内容放在`请求体`中提交，controller用一个blog形参对象接收；  
2.从ThreadLocal获取用户id，放入blog对象；  
3.将blog对象存入数据库中blog表；  
![在这里插入图片描述][4bfd647f44e6456c8285506f0da87e0c.png]

### 4.2 查看笔记（返回blog对象+作者信息） ###

![在这里插入图片描述][4ed15403aa034601844037fbcfd2ae02.png]

**准备**：由于用户的头像和姓名并不在blog对象中，所以在blog实体类中使用 `@TableField(exist=false)` 添加头像和姓名这两个属性；

**流程**：  
1.前端提交笔记id，后端根据笔记id从数据库查到 blog对象；不存在则返回错误；  
2.存在则根据blog取到作者的userid；  
3.根据userid从user表获取用户头像和姓名，封装到 blog对象，最后返回blog对象给前端；

![在这里插入图片描述][3f58c6f82f524b70907cccd422812a10.png]  
![在这里插入图片描述][cffb7fcf620446998e351e7febc3a95f.png]

### 4.3 实现点赞功能 ###

#### 需求一： ####

**一个用户只能点一次赞，再点赞则取消；**

**流程**：  
1.从ThreadLocal获取user对象，拿到userid；  
2.用Sismember在Redis的set集合判断是否点赞过，（防止一个用户反复点赞） key=blogid，value=userid  
①未点赞过则数据库like+1，将userID放入Redis的set；（先数据库再Redis）  
②已点赞过则数据库like-1，将userID移除Redis的set；  
3.打开首页时（分页查询），会根据笔记ID查询blog，通过set判断当前用户是否点赞过，是则赋值给isLike字段，会由前端显示高亮；  
4.分页查询blog业务时，通过set判断当前用户是否点赞过，是则赋值给isLike字段；  
![在这里插入图片描述][ad65f2953f2d445baba34fb429428edb.png]  
![在这里插入图片描述][64c25b5a06b94c27a8c114e88088162c.png]

#### 需求二： ####

**查看当前用户是否点过赞，点过则点赞按钮`高亮显示`（判断字段isLike属性），【需要在查询的时候才判断】！**  
**准备**：  
给blog实体类添加`isLike`字段（TableField(exist=false)），标识是否被当前用户点赞；  
![在这里插入图片描述][4c9dca95163e48e9a2ddeac407eafc4b.png]  
1.当查询某一个笔记时，判断当前用户是否点赞过，是则赋值给isLike字段  
将赋值的操作封装到函数isBlogLiked：  
![在这里插入图片描述][5a2a8296682f49e99fcff0e4eb628aa5.png]  
isBlogUser函数：  
从Threadlocal获取userid；  
isMember查询set中是否有userid；  
赋值给isLike字段；  
![在这里插入图片描述][801470b87e1b424b888c34339c8692f9.png]

2.首页的分页查询，也调用isBlogUser函数；  
![在这里插入图片描述][294bd56696dc452999ce5a486551904f.png]  
**效果**：当前用户高亮；  
![在这里插入图片描述][0bca6e9f2e7341ae85ad2015110751e3.png]

[8b42d360835a4203a47be39f5c9da7f6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/c8f8ad730bb44887a044468f4bfacc71.png
[eef4b7ea8ce0414b8888cea837f13ffd.png]: https://img-blog.csdnimg.cn/eef4b7ea8ce0414b8888cea837f13ffd.png
[4d2f799365b44c4995b9f32e7a500075.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/f138f508fbfb4cfa99087d7fb8ae0937.png
[9fc4e91947654c4eb83bde155d01b579.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/8da072b8fef043b1a6fec39ebfea97c9.png
[a6427eca7b824680ac4e47fd4b32bc47.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/879753fcd15a4445b76dc4bff50c7f43.png
[f6d4ad7415dd49a2bfa590d9e9ec4d77.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/d42eabd221214f4382f46ac1574bd4c8.png
[e19c6c7a0a474f8c9f08467ac63500c0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/3d44c58ca27743bbb289c2c208bb601e.png
[dd4dcc03bcee47eaaeac9b92279fba26.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/565b4a0b306247c28e56a278a2e9056e.png
[1e65ca0f3a194c5a9c1d8e81c86e6ad5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/f96d7a16d27b4606a0007782d53679ad.png
[1472ba77691549f19571ff77ddd1b044.png]: https://img-blog.csdnimg.cn/1472ba77691549f19571ff77ddd1b044.png
[5263eaed2d714148b0ebbd17fc439f8a.png]: https://img-blog.csdnimg.cn/5263eaed2d714148b0ebbd17fc439f8a.png
[54bc449e8ba44bf8a9e9dda206ea76d0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/70a737c3145a4e37ae95fd5b50b96477.png
[0ffbb31a1607454d9885c498cf3cb03b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/55b501b41a7242a9882ecb7c6a1c4223.png
[b79698511ecc44d0acfb54476f8ce043.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/5d07e8014ed3454195c0045a6a6c98c0.png
[414f31e24e13471a8ca4a744cfe35036.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/33a45acc9d004d53b6951874312fd27c.png
[f4108e4a070c417d8629788797dbf9f1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/eea9afbf81ac43af98404355f0bf7b3d.png
[64030218ab534e45998f9a769c620be0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/dfa5531cdeac4e10b658e2dc53ca0ebe.png
[f337db91213b4fb59b97414308b5757f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/aa9b21ace915455387830567e8dbfd7d.png
[Link 1]: https://blog.csdn.net/Swofford/article/details/129158429?spm=1001.2014.3001.5501
[Link 2]: https://blog.csdn.net/Swofford/article/details/129168666
[ID]: https://blog.csdn.net/Swofford/article/details/129206270
[65584889249d431d89d3296ff58575aa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/8f717aade64f4d3b8979b063e2cc2cc4.png
[b57c85bb70d845b6be6deb93e1059c03.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/74f1c8c96c16434586aaee02c2066942.png
[eb773fef8aec4664ac77690c7d1b285f.png]: https://img-blog.csdnimg.cn/eb773fef8aec4664ac77690c7d1b285f.png
[d4ee8c0c4d7a4473a367c70f66bbe246.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/87e51a287b6240389a5a47e8d2d7cc92.png
[1cd773dbeb79447d9a92075392dd3a6d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/49f23d710b9b4442aa28c3caab63ef76.png
[faa069ccc0b44a8197b446a6c7418b15.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/bf715d94c4fd4a5ca8ae2dc365d209b0.png
[367bd51509634acaa03f68f8d9b58bbc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/012c289b54b743a7b3389e9972674ac6.png
[84af3dbce14043e8ba6190d0d172366e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/4226b58cfd6c4237a152f583fc5e93b8.png
[c0d1d9f8d9524eb38d4d906d7f6f5c7a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/65c13d3936d34d629d3fb0997a533a62.png
[7177062cf4ab4eee9ea96b6a061c1a6b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/6167c6e449f14860b9ace5bdd604786b.png
[619b13511a904615a66c20375a0b17d4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/18b8c8e3c7294151ad8bf316db0d1da8.png
[88f7fb96b17743b3af20f5318049269a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/ceb073aa6b7f4cbd89d1bb9d58c95145.png
[ae9c4cc0f89e46389f3282b2c39eaa34.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/c6a998a8b7814264bb95999075b25ec6.png
[302a026bdd494185a0c92c3dc00a31bc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/e2166c83cc9d4263b8d1de8419035d7f.png
[3e3e97c4efcf4f7dbca2248e768a7d3e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/6c213e4ca305489db4809c057a1b8361.png
[20f6f8b29bd148f39c7fb1453650553d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/325908f68f3b472fbfccf4374e6b6d3b.png
[6c790eb716af424896e807b0edca5343.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/9018282cfe8d4acfb022326e636284f7.png
[f983eece56d3449ab647781ef623f7f1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/5832a7b36699460e80860a51406be3b5.png
[Link 3]: https://blog.csdn.net/Swofford/article/details/129248704?spm=1001.2014.3001.5502
[06b38c3b20524eaa9a85de1abe28e21a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/6bf3335844d644259e090f458b2c17f5.png
[7df1fd9cfbf745f7959fe3a1685423d3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/d7a339afc70847d59ec60a0430691b16.png
[9e4e496ac9b341e7a2b6cdf2e7b4d6a5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/3199cc9fceef498ba65bcd3e5645057e.png
[cd993c532fb14a9a9ba63bef16a17408.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/98afe6e2be6349b5b23a9146c6e73085.png
[fd60973c7acf4b8cb8e2079336af768b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/d74356b47ddc4015a3db7d56995d5af9.png
[757060c96e3a4d108814f00fc97d204a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/a438a7924b7a4bd3901fe13970b44a94.png
[743606cb253f47dc98ae00b1fbc53b96.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/eee994f35da6425a9d4c268d3b85a880.png
[897b09a8fe64494fbf5ed9c5ab1dbdc7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/d5b321b82856477a9643ea72dcd56d47.png
[f331de63500f4e778a3a1a6da724f7a7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/0aaa14970ece4103ab8f466e0530e0a5.png
[5a127afe39fe48dba7ee8a8d3c8bc5df.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/9a0fb0df13dc43f09d4f8f7c44b474ab.png
[6f2e86b990ba4c94a31d597cad108210.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/2ef18dcdf09f46a48fce8963a97f6234.png
[6217f4852b734af59ed7228e105fcb7b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/326d6ecc72864c3c8b441e9c879d2df4.png
[a9e2c8064f874e33b7d7ef5f4609ddfd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/9b66d69f848c41569602fd1e306a1e5d.png
[cef0a1d612954ef7b0e3e727b9f76e07.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/ea0ac28182ac4a27addfb1d272595b7a.png
[9735015eab5b470da37bb51a2a8ee7f1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/e12c52080ada42f288274962a81c8113.png
[285b55bc93cb4b12a572668acc9a2713.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/9726a1e4d66940aab0640581ae18a002.png
[4bfd647f44e6456c8285506f0da87e0c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/61f870f2933546a2bf594f122cacf661.png
[4ed15403aa034601844037fbcfd2ae02.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/05f8b9e4eeeb40328a9e215ac7098ae7.png
[3f58c6f82f524b70907cccd422812a10.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/90862b239679416abf32404e78990c64.png
[cffb7fcf620446998e351e7febc3a95f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/cef99e0c9dfc44719e7e7581c9ff7acc.png
[ad65f2953f2d445baba34fb429428edb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/56f92544f37a497982cc119bbbf26ac5.png
[64c25b5a06b94c27a8c114e88088162c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/9050d2f5b73e440ea228391bc4d7e84e.png
[4c9dca95163e48e9a2ddeac407eafc4b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/562f74f5ef1844229702d799de88dc95.png
[5a2a8296682f49e99fcff0e4eb628aa5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/75a3172b94fc43d283aaa0406f61eae1.png
[801470b87e1b424b888c34339c8692f9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/902e4da09293452fa84dad3728a26b89.png
[294bd56696dc452999ce5a486551904f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/b8224a2c99ea431f8e65bb4247a9df16.png
[0bca6e9f2e7341ae85ad2015110751e3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/b320211abef849ee8779889f6eba39ad.png