springboot-redis-mysql-nginx项目：黑马点评开发

开篇导读

亲爱的小伙伴们大家好，希望通过此博客，小伙伴们就能理解各种redis的使用啦。

短信登录

这一块我们会使用redis共享session来实现

商户查询缓存

通过本章节，我们会理解缓存击穿，缓存穿透，缓存雪崩等问题，让小伙伴的对于这些概念的理解不仅仅是停留在概念上，更是能在代码中看到对应的内容

优惠卷秒杀

通过本章节，我们可以学会Redis的计数器功能，结合Lua完成高性能的redis操作，同时学会Redis分布式锁的原理，包括Redis的三种消息队列

附近的商户

我们利用Redis的GEOHash来完成对于地理坐标的操作

UV统计

主要是使用Redis来完成统计功能

用户签到

使用Redis的BitMap数据统计功能

好友关注

基于Set集合的关注、取消关注，共同关注等等功能，这一块知识咱们之前就讲过，这次我们在项目中来使用一下

达人探店

基于List来完成点赞列表的操作，同时基于SortedSet来完成点赞的排行榜功能

以上这些内容咱们统统都会给小伙伴们讲解清楚，让大家充分理解如何使用Redis

1.前期准备

资料链接：
链接https://pan.baidu.com/s/1189u6u4icQYHg_9_7ovWmA?pwd=eh11
提取码：eh11

1.1redis的安装与使用

1.1.1linux安装redis

[linux虚拟机安装redis]: linux虚拟机安装redis全步骤,解决了本地虚拟机手动移动文件报错的问题_登峰灬造極的博客-CSDN博客

1.2 nginx部署运行前端项目

对于怎么开发一个前端的模块以及怎么部署，在后续会另写一个博客。此处值说明怎么将文件中的前端项目部署起来

导入前端项目

我将此文件解压到与后端项目的同一路径下，便于整理。

运行前端项目

(1) 双击nginx.exe，有黑窗口一闪而过就是启动成功

(2)

此时运行的前端项目应该是没有数据库中的数据以及其他文件的，运行起来浏览器的控制台也会报资源请求错误。在后端模块运行起来之后就可以加载到数据了。

3.关闭ngnix
Nginx软件启动后只能通过命令行来进行关闭，三种关闭方法如下：

1. nginx -s stop //快速停止Nginx2. nginx -s quit //有序的停止Nginx3. taskkill /F /IM nginx.exe > nul

（1）这两个关闭方法是比较常用的两种，使用这两个命令时必须要在安装包路径下，否则系统无法找到Nginx；
（2）这两个命令的区别在于nginx -s stop是快速停止Nginx，而nginx -s quit是有序的停止Nginx，前者可能会导致数据没有完全保存；

（3）这种方法可以直接在cmd命令面板上使用，不必跑到Nginx的安装包下运行，当前两种方法无法奏效时可以尝试使用此方法，前两种方法适用于大部分版本的Nginx，但是个别版本的可能不使用，使用这个基本上就能解决了~

**注意：**关闭Nginx后可能会发现浏览器上仍然可以访问localhost:80这个页面，那是因为浏览器的缓存机制导致的，只需要 F5 刷新一下浏览器就可以了~

1.3 mysql数据库文件导入数据库

创建hmdp数据库

CREATE DATABASE `hmdp` CHARACTER SET 'utf8';

运行sql文件

由于sql文件中并没有指定数据库，所以需要进入数据库后在运行sql，以Navicat Premium 为例：

以文本打开sql文件

将sql复制到Navicat Premium中或者mysql的可视化界面，黑窗口使用use hmdp 进入该数据库

数据库导入成功

2. 项目搭建

2.1 项目模型

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

**分析：**本项目实现了前后端分离，但并没有对前后端进行微服务模块划分，因为这个项目的重点在于对redis的操作以及对于redis的一些问题做出对应的解决措施。

2.2 导入后端项目

server:port: 8081 #项目端口
spring:application:name: hmdp #项目名datasource:#对于mysql 8 版本的改为 com.mysql.cj.jdbc.Driver  再在pom.xml中改mysql驱动的版本driver-class-name: com.mysql.jdbc.Driverurl: jdbc:mysql://127.0.0.1:3306/hmdp?useSSL=false&serverTimezone=UTCusername: root #数据库的账号password: 123456 #数据库密码redis:
# redis的主机地址host: 192.168.132.128 #linux虚拟机的地址
#redis的端口port: 6379
#redis的密码password: 123321lettuce:pool:
# 连接配置max-active: 10max-idle: 10min-idle: 1time-between-eviction-runs: 10sjackson:default-property-inclusion: non_null # JSON处理时忽略非空字段
mybatis-plus:type-aliases-package: com.hmdp.entity # 别名扫描包
logging:level:com.hmdp: debug

此时浏览器应该是一些json数据，当前端、后端成功运行起来时，此时就可以通过http://localhost:8080访问到有数据的页面，但是没有实现功能，这就是我们需要做的。

2.3 后端项目分析

2.3.1 项目结构

2.3.2 maven依赖分析

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>2.3.12.RELEASE</version><relativePath/> <!-- lookup parent from repository --></parent><groupId>com.hmdp</groupId><artifactId>hm-dianping</artifactId><version>0.0.1-SNAPSHOT</version><name>hm-dianping</name><description>Demo project for Spring Boot</description><properties><java.version>1.8</java.version></properties><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId></dependency><!--Apache 开源的对象池框架--><dependency><groupId>org.apache.commons</groupId><artifactId>commons-pool2</artifactId></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><!--mysql驱动 mysql8版本将版本改到8版本--><dependency><groupId>mysql</groupId><artifactId>mysql-connector-java</artifactId><scope>runtime</scope><version>5.1.47</version></dependency><!--注解生成实体类的构造方法，getset，tostring等等--><dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId><optional>true</optional></dependency><!--测试--><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope></dependency><!--mybatisplus--><dependency><groupId>com.baomidou</groupId><artifactId>mybatis-plus-boot-starter</artifactId><version>3.4.3</version></dependency><!--hutool 工具包--><dependency><groupId>cn.hutool</groupId><artifactId>hutool-all</artifactId><version>5.7.17</version></dependency></dependencies><!--打包方式--><build><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId><configuration><excludes><exclude><!--打包不包括lombok的一些东西，我忘了--><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId></exclude></excludes></configuration></plugin></plugins></build></project>

3. 功能实现

3.1 登录功能

3.1.1 基于Session实现登录流程

发送验证码：

用户在提交手机号后，会校验手机号是否合法，如果不合法，则要求用户重新输入手机号

如果手机号合法，后台此时生成对应的验证码，同时将验证码进行保存，然后再通过短信的方式将验证码发送给用户

短信验证码登录、注册：

用户将验证码和手机号进行输入，后台从session中拿到当前验证码，然后和用户输入的验证码进行校验，如果不一致，则无法通过校验，如果一致，则后台根据手机号查询用户，如果用户不存在，则为用户创建账号信息，保存到数据库，无论是否存在，都会将用户信息保存到session中，方便后续获得当前登录信息

校验登录状态:

用户在请求时候，会从cookie中携带者JsessionId到后台，后台通过JsessionId从session中拿到用户信息，如果没有session信息，则进行拦截，如果有session信息，则将用户信息保存到threadLocal中，并且放行

代码编写：

发送验证码

在userController中/*** 发送手机验证码*/@PostMapping("code")public Result sendCode(@RequestParam("phone") String phone, HttpSession session) {// TODO 发送短信验证码并保存验证码return userService.sendCode(phone,session);}在userService中/*** 生成验证码* @param phone* @param session* @return*/Result sendCode(String phone, HttpSession session);在userServiceImpl中在userServiceImpl类上添加注解，开启日志@Slf4j/*** 生成验证码* @param phone* @param session* @return*/@Overridepublic Result sendCode(String phone, HttpSession session) {//1.校验手机号if(RegexUtils.isPhoneInvalid(phone)){//2.如果不符合，返回错误信息return Result.fail("手机号格式错误！");}//3.符合，生成验证码String code = RandomUtil.randomNumbers(6);//4.保存验证码到sessionsession.setAttribute("code",code);//5.发送验证码log.debug("发送短信验证码成功，验证码：{}",code);//返回okreturn Result.ok();}

在userController中
/*** 登录功能* @param loginForm 登录参数，包含手机号、验证码；或者手机号、密码*/@PostMapping("/login")public Result login(@RequestBody LoginFormDTO loginForm, HttpSession session){//实现登录功能return userService.login(loginForm,session);}在userService中/*** 实现登录* @param loginForm* @param session* @return*/Result login(LoginFormDTO loginForm, HttpSession session);  在userServiceImpl中@Overridepublic Result login(LoginFormDTO loginForm, HttpSession session) {//1.校验手机号String phone = loginForm.getPhone();if(RegexUtils.isPhoneInvalid(phone)){//2.如果不符合，返回错误信息return Result.fail("手机号格式错误！");}//2.校验验证码Object cachecode = session.getAttribute("code");String code = loginForm.getCode();if(cachecode == null || !cachecode.toString().equals(code)){//3.不一致，报错return Result.fail("验证码错误");}//4.一致，根据手机号查询用户 select * from tb_user where phone = ?User user = query().eq("phone", phone).one();//5.判断用户是否存在if(user == null){//6.不存在,创建用户并保存user = creatUserWithPhone(phone);}//7.保存用户信息到session中session.setAttribute("user",user);return Result.ok();}/*** 根据手机号创建用户* @param phone* @return*/private User creatUserWithPhone(String phone) {//1.创建用户User user = new User();user.setPhone(phone);user.setNickName(USER_NICK_NAME_PREFIX + RandomUtil.randomString(10));//2.保存用户save(user);return user;}

此时，我们在前端页面点击发送验证码，后端就会打印出验证码，而我们现实将验证码发送到手机则可以通过腾讯云来实现，后面有机会可以补充一下此功能。

3.1.2实现登录拦截功能

温馨小贴士：tomcat的运行原理

当用户发起请求时，会访问我们像tomcat注册的端口，任何程序想要运行，都需要有一个线程对当前端口号进行监听，tomcat也不例外，当监听线程知道用户想要和tomcat连接连接时，那会由监听线程创建socket连接，socket都是成对出现的，用户通过socket像互相传递数据，当tomcat端的socket接受到数据后，此时监听线程会从tomcat的线程池中取出一个线程执行用户请求，在我们的服务部署到tomcat后，线程会找到用户想要访问的工程，然后用这个线程转发到工程中的controller，service，dao中，并且访问对应的DB，在用户执行完请求后，再统一返回，再找到tomcat端的socket，再将数据写回到用户端的socket，完成请求和响应

通过以上讲解，我们可以得知每个用户其实对应都是去找tomcat线程池中的一个线程来完成工作的，使用完成后再进行回收，既然每个请求都是独立的，所以在每个用户去访问我们的工程时，我们可以使用threadlocal来做到线程隔离，每个线程操作自己的一份数据

温馨小贴士：关于threadlocal

如果小伙伴们看过threadLocal的源码，你会发现在threadLocal中，无论是他的put方法和他的get方法，都是先从获得当前用户的线程，然后从线程中取出线程的成员变量map，只要线程不一样，map就不一样，所以可以通过这种方式来做到线程隔离

拦截器代码

//在untils中创建类public class LoginInterceptor implements HandlerInterceptor {@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {//1.获取sessionHttpSession session = request.getSession();//2.获取session中的用户Object user = session.getAttribute("user");//3.判断用户是否存在if(user == null){//4.不存在，拦截，返回401状态码response.setStatus(401);return false;}`//5.存在，保存用户信息到Threadlocal//如果报错需要一个USerDTO类型就将UserHolder中的userDTO换成user，后面要换回来，因为信息敏感问题    UserHolder.saveUser((User)user);//6.放行return true;}
}

让拦截器生效

@Configuration  //配置类注解
public class MvcConfig implements WebMvcConfigurer {@Overridepublic void addInterceptors(InterceptorRegistry registry) {// 登录拦截器registry.addInterceptor(new LoginInterceptor())//不拦截那些路径的请求    .excludePathPatterns("/shop/**","/voucher/**","/shop-type/**","/upload/**","/blog/hot","/user/code","/user/login")//将此拦截器的优先级调到1 越大越晚.order(1);}
}

3.1.3隐藏用户敏感信息

我们通过浏览器观察到此时用户的全部信息都在，这样极为不靠谱，所以我们应当在返回用户信息之前，将用户的敏感信息进行隐藏，采用的核心思路就是书写一个UserDto对象，这个UserDto对象就没有敏感信息了，我们在返回前，将有用户敏感信息的User对象转化成没有敏感信息的UserDto对象，那么就能够避免这个尴尬的问题了

在登录方法处修改

//7.保存用户信息到session中
session.setAttribute("user",BeanUtils.copyProperties(user,UserDTO.class));
//再此使用了hutool 工具包的方法,当然也可以自己写,将两个类进行转换

在UserHolder处：将user对象换成UserDTO

public class UserHolder {private static final ThreadLocal<UserDTO> tl = new ThreadLocal<>();public static void saveUser(UserDTO user){tl.set(user);}public static UserDTO getUser(){return tl.get();}public static void removeUser(){tl.remove();}
}

此时我们可以成功的将用户信息保存到session中了，并且也解决了用户信息敏感的问题，但是，在实际开发中，我们的项目并不是部署在一个服务器上，特别是后面微服务项目的开发，如果我们使用session来实现信息共享，就会导致大量重复信息，增大服务器压力

3.1.4session共享问题

核心思路分析：

每个tomcat中都有一份属于自己的session,假设用户第一次访问第一台tomcat，并且把自己的信息存放到第一台服务器的session中，但是第二次这个用户访问到了第二台tomcat，那么在第二台服务器上，肯定没有第一台服务器存放的session，所以此时整个登录拦截功能就会出现问题，我们能如何解决这个问题呢？早期的方案是session拷贝，就是说虽然每个tomcat上都有不同的session，但是每当任意一台服务器的session修改时，都会同步给其他的Tomcat服务器的session，这样的话，就可以实现session的共享了

但是这种方案具有两个大问题

1、每台服务器中都有完整的一份session数据，服务器压力过大。

2、session拷贝数据时，可能会出现延迟

所以咱们后来采用的方案都是基于redis来完成，我们把session换成redis，redis数据本身就是共享的，就可以避免session共享的问题了

3.1.5 Redis代替session的业务流程

3.1.5.1设计key的结构

首先我们要思考一下利用redis来存储数据，那么到底使用哪种结构呢？由于存入的数据比较简单，我们可以考虑使用String，或者是使用哈希，如下图，如果使用String，同学们注意他的value，用多占用一点空间，如果使用哈希，则他的value中只会存储他数据本身，如果不是特别在意内存，其实使用String就可以啦。

3.1.5.2设计key的具体细节

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

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

1、key要具有唯一性

2、key要方便携带

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

3.1.5.3整体访问流程

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

3.1.6 基于Redis实现短信登录

UserServiceImpl代码

@Override
public Result login(LoginFormDTO loginForm, HttpSession session) {// 1.校验手机号String phone = loginForm.getPhone();if (RegexUtils.isPhoneInvalid(phone)) {// 2.如果不符合，返回错误信息return Result.fail("手机号格式错误！");}// 3.从redis获取验证码并校验String cacheCode = stringRedisTemplate.opsForValue().get(LOGIN_CODE_KEY + phone);String code = loginForm.getCode();if (cacheCode == null || !cacheCode.equals(code)) {// 不一致，报错return Result.fail("验证码错误");}// 4.一致，根据手机号查询用户 select * from tb_user where phone = ?User user = query().eq("phone", phone).one();// 5.判断用户是否存在if (user == null) {// 6.不存在，创建新用户并保存user = createUserWithPhone(phone);}// 7.保存用户信息到 redis中// 7.1.随机生成token，作为登录令牌String token = UUID.randomUUID().toString(true);// 7.2.将User对象转为HashMap存储UserDTO userDTO = BeanUtil.copyProperties(user, UserDTO.class);/** 由于StringRedisTemplate中的redis数据为Map<String，String>,我们需要将UserDTO中private Long id; 转为String//将UserDTO转换成hashMap,(fieldName,fieldValue) -> fieldValue.toString())//将UserDTO中的变量名对应的值转化成String类型*/Map<String, Object> userMap = BeanUtil.beanToMap(userDTO, new HashMap<>(),CopyOptions.create().setIgnoreNullValue(true).setFieldValueEditor((fieldName, fieldValue) -> fieldValue.toString()));// 7.3.存储 LOGIN_USER_KEY:RedisConstants自定义工具类的常量，提高代码正确性String tokenKey = LOGIN_USER_KEY + token;stringRedisTemplate.opsForHash().putAll(tokenKey, userMap);// 7.4.设置token有效期stringRedisTemplate.expire(tokenKey, LOGIN_USER_TTL, TimeUnit.MINUTES);// 8.返回tokenreturn Result.ok(token);
}

Long转String异常：

3.1.7解决状态登录刷新问题

3.1.7.1初始方案思路总结：

在这个方案中，他确实可以使用对应路径的拦截，同时刷新登录token令牌的存活时间，但是现在这个拦截器他只是拦截需要被拦截的路径，假设当前用户访问了一些不需要拦截的路径，那么这个拦截器就不会生效，所以此时令牌刷新的动作实际上就不会执行，所以这个方案他是存在问题的

3.1.7.2 优化方案

既然之前的拦截器无法对不需要拦截的路径生效，那么我们可以添加一个拦截器，在第一个拦截器中拦截所有的路径，把第二个拦截器做的事情放入到第一个拦截器中，同时刷新令牌，因为第一个拦截器有了threadLocal的数据，所以此时第二个拦截器只需要判断拦截器中的user对象是否存在即可，完成整体刷新功能。

在utils中创建RefreshTokenInterceptor

public class RefreshTokenInterceptor implements HandlerInterceptor {private StringRedisTemplate stringRedisTemplate; /*** 为什么写构造函数去初始化redis，因为此类并不在bean容器中，我们无法通过注解去获取redis对象* 而是在配置类中实现类去获取,当然我们也可以将此类加入到bean中在去获取,各有优势* @param stringRedisTemplate*/public RefreshTokenInterceptor(StringRedisTemplate stringRedisTemplate) {this.stringRedisTemplate = stringRedisTemplate;}@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {// 1.获取请求头中的tokenString token = request.getHeader("authorization");if (StrUtil.isBlank(token)) {//如果少了这个判断，在后续代码中会出现空指针异常//放行return true;}// 2.基于TOKEN获取redis中的用户String key  = LOGIN_USER_KEY + token;Map<Object, Object> userMap = stringRedisTemplate.opsForHash().entries(key);// 3.判断用户是否存在if (userMap.isEmpty()) {//如果少了这个判断，在后续代码中会出现空指针异常//放行return true;}// 5.将查询到的hash数据转为UserDTOUserDTO userDTO = BeanUtil.fillBeanWithMap(userMap, new UserDTO(), false);// 6.存在，保存用户信息到 ThreadLocalUserHolder.saveUser(userDTO);// 7.刷新token有效期stringRedisTemplate.expire(key, LOGIN_USER_TTL, TimeUnit.MINUTES);// 8.放行return true;}@Overridepublic void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {// 移除用户UserHolder.removeUser();}
}

LoginInterceptor

public class LoginInterceptor implements HandlerInterceptor {@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {// 1.判断是否需要拦截（ThreadLocal中是否有用户）if (UserHolder.getUser() == null) {// 没有，需要拦截，设置状态码response.setStatus(401);// 拦截return false;}// 有用户，则放行return true;}//删除afterCompletion()
}

对于本项目的短信登录功能就完整实现了。

3.1.8 手机号密码登录

非常简单

 @Overridepublic Result login(LoginFormDTO loginForm, HttpSession session) {//1.校验手机号String phone = loginForm.getPhone();if(RegexUtils.isPhoneInvalid(phone)){//1.1.如果不符合，返回错误信息return Result.fail("手机号格式错误！");}//2.根据手机号查询用户 select * from tb_user where phone = ?User user = query().eq("phone", phone).one();//3判断登录密码是否为空if(!loginForm.getPassword().isEmpty()){//3.1密码登录if(user == null){//3.2用户不存在return Result.fail("你还没有注册账户呢，赶紧用手机号去注册账户吧");}if (!user.getPassword().equals(loginForm.getPassword())) {//3.3密码错误return Result.fail("手机号或者密码错误");}}//4验证码登录else {//4.1.从redis获取验证码并校验String cachecode = stringRedisTemplate.opsForValue().get(LOGIN_CODE_KEY + phone);String code = loginForm.getCode();if(cachecode == null || !cachecode.toString().equals(code)){//4.2.不一致，报错return Result.fail("验证码错误");}//4.3.判断用户是否存在if(user == null){//4.4.不存在,创建用户并保存user = creatUserWithPhone(phone);}}//5.保存用户信息到redis中 ,将user转成UserDTO只在session中保存基本信息//5.1 随机生成token，作为登录令牌//import cn.hutool.core.lang.UUID;String token = UUID.randomUUID().toString(true);//5.2将User对象转为Hash存储UserDTO userDTO = BeanUtil.copyProperties(user, UserDTO.class);//将UserDTO转换成hashMap,(fieldName,fieldValue) -> fieldValue.toString())//将UserDTO中的变量名对应的值转化成String类型Map<String, Object> userMap = BeanUtil.beanToMap(userDTO,new HashMap<>(),CopyOptions.create().setIgnoreNullValue(true).setFieldValueEditor((fieldName,fieldValue) -> fieldValue.toString()));//5.3存储String tokenKey = LOGIN_USER_KEY+token;stringRedisTemplate.opsForHash().putAll(tokenKey,userMap);//5.4设置token有效期stringRedisTemplate.expire(tokenKey,LOGIN_USER_TTL,TimeUnit.MINUTES);//6返回tokenreturn Result.ok(token);}

测试：

测试成功！

3.2商铺查询缓存

3.2.1 什么是缓存?

3.2.1.1前言:什么是缓存?

就像自行车,越野车的避震器

举个例子:越野车,山地自行车,都拥有"避震器",防止车体加速后因惯性,在酷似"U"字母的地形上飞跃,硬着陆导致的损害,像个弹簧一样;

同样,实际开发中,系统也需要"避震器",防止过高的数据访问猛冲系统,导致其操作线程无法及时处理信息而瘫痪;

这在实际开发中对企业讲,对产品口碑,用户评价都是致命的;所以企业非常重视缓存技术;

缓存(Cache),就是数据交换的缓冲区,俗称的缓存就是缓冲区内的数据,一般从数据库中获取,存储于本地代码(例如:

例1:Static final ConcurrentHashMap<K,V> map = new ConcurrentHashMap<>(); 本地用于高并发例2:static final Cache<K,V> USER_CACHE = CacheBuilder.newBuilder().build(); 用于redis等缓存例3:Static final Map<K,V> map =  new HashMap(); 本地缓存

3.2.1.2 为什么要使用缓存

一句话:因为速度快,好用

缓存数据存储于代码中,而代码运行在内存中,内存的读写性能远高于磁盘,缓存可以大大降低用户访问并发量带来的服务器读写压力

实际开发过程中,企业的数据量,少则几十万,多则几千万,这么大数据量,如果没有缓存来作为"避震器",系统是几乎撑不住的,所以企业会大量运用到缓存技术;

但是缓存也会增加代码复杂度和运营的成本:

3.2.1.3如何使用缓存

实际开发中,会构筑多级缓存来使系统运行速度进一步提升,例如:本地缓存与redis中的缓存并发使用

浏览器缓存：主要是存在于浏览器端的缓存

**应用层缓存：**可以分为tomcat本地缓存，比如之前提到的map，或者是使用redis作为缓存

**数据库缓存：**在数据库中有一片空间是 buffer pool，增改查数据都会先加载到mysql的缓存中

**CPU缓存：**当代计算机最大的问题是 cpu性能提升了，但内存读写速度没有跟上，所以为了适应当下的情况，增加了cpu的L1，L2，L3级的缓存

3.2.2添加商户缓存

在我们查询商户信息时，我们是直接操作从数据库中去进行查询的，大致逻辑是这样，直接查询数据库那肯定慢咯，所以我们需要增加缓存

@GetMapping("/{id}")
public Result queryShopById(@PathVariable("id") Long id) {//这里是直接查询数据库return shopService.queryById(id);
}

3.2.2.1缓存模型和思路

标准的操作方式就是查询数据库之前先查询缓存，如果缓存数据存在，则直接从缓存中返回，如果缓存数据不存在，再查询数据库，然后将数据存入redis。

代码如下：

代码思路：如果缓存有，则直接返回，如果缓存不存在，则查询数据库，然后存入redis。

@ResourceStringRedisTemplate stringRedisTemplate;/*** 根据id查询商铺，使用redis缓存* @param id* @return*/@Overridepublic Result qureyById(Long id) {String key =CACHE_SHOP_KEY + id;//1.从redis查询商铺缓存String shopJson = stringRedisTemplate.opsForValue().get(key);//2.判断是否存在if(StrUtil.isNotBlank(shopJson)){//StrUtil.isNotBlank()参数是null,"",都是false//3.存在，返回Shop shop = JSONUtil.toBean(shopJson, Shop.class);return Result.ok(shop);}//判断命中是否是空值if(shopJson != null){//返回一个错误信息return Result.fail("店铺信息不存在!");}//4.不存在，根据id查询数据库Shop shop = getById(id);if(shop == null){//5.不存在，返回错误return Result.fail("店铺不存在！");}//6.存在.写入redisstringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(shop));//7.返回return Result.ok(shop);}

3.2.2.2 添加商铺缓存

同样的我们也是一样的思路，但是商铺是一个集合，所以我使用list来存储。

//在ShopTypeController
@GetMapping("list")public Result queryTypeList() {//给店铺分类加入redisList<ShopType> typeList = typeService.queryOrderByAsc();return Result.ok(typeList);}//在ShopTypeServiceImpl实现queryOrderByAsc()@ResourceStringRedisTemplate stringRedisTemplate;/*** 查询所有的店铺分类* @return**/@Overridepublic List<ShopType> queryOrderByAsc() {//初始化商铺类别集合List<ShopType> shopTypes = new ArrayList<>();//1.从redis中查询店铺分类信息Long types = stringRedisTemplate.opsForList().size(CACHE_SHOP_TYPE_KEY);//2.存在if( types> 0){//取出所有的数据List<String> shops = stringRedisTemplate.opsForList().range(CACHE_SHOP_TYPE_KEY, 0, types);for (int i = 0; i < types; i++) {//将redis中的数据转换ShopType shopType = JSONUtil.toBean(shops.get(i),ShopType.class);//加入集合shopTypes.add(shopType);}//返回return shopTypes;}//3.不存在，去数据库查询信息shopTypes = query().orderByAsc("sort").list();if(shopTypes.size() <= 0){//4.不存在，返回错误信息return shopTypes;}//5.存在,将信息存入redisfor (int i = 0; i < shopTypes.size(); i++) {stringRedisTemplate.opsForList().leftPush(CACHE_SHOP_TYPE_KEY,JSONUtil.toJsonStr(shopTypes.get(i)));}//6.返回return shopTypes;}

**效果展示：**快了一倍，这就是缓存的吗，太快了

3.2.3缓存更新策略

缓存更新是redis为了节约内存而设计出来的一个东西，主要是因为内存数据宝贵，当我们向redis插入太多数据，此时就可能会导致缓存中的数据过多，所以redis会对部分数据进行更新，或者把他叫为淘汰更合适。

**内存淘汰：**redis自动进行，当redis内存达到咱们设定的max-memery的时候，会自动触发淘汰机制，淘汰掉一些不重要的数据(可以自己设置策略方式)

**超时剔除：**当我们给redis设置了过期时间ttl之后，redis会将超时的数据进行删除，方便咱们继续使用缓存

**主动更新：**我们可以手动调用方法把缓存删掉，通常用于解决缓存和数据库不一致问题

3.2.3.1数据库缓存不一致解决方案

由于我们的缓存的数据源来自于数据库,而数据库的数据是会发生变化的,因此,如果当数据库中数据发生变化,而缓存却没有同步,此时就会有一致性问题存在,其后果是:

用户使用缓存中的过时数据,就会产生类似多线程数据安全问题,从而影响业务,产品口碑等;怎么解决呢？有如下几种方案

Cache Aside Pattern 人工编码方式：缓存调用者在更新完数据库后再去更新缓存，也称之为双写方案

Read/Write Through Pattern : 由系统本身完成，数据库与缓存的问题交由系统本身去处理

Write Behind Caching Pattern ：调用者只操作缓存，其他线程去异步处理数据库，实现最终一致

3.2.3.2数据库和缓存不一致采用什么方案

综合考虑使用方案一，但是方案一调用者如何处理呢？这里有几个问题

操作缓存和数据库时有三个问题需要考虑：

如果采用第一个方案，那么假设我们每次操作数据库后，都操作缓存，但是中间如果没有人查询，那么这个更新动作实际上只有最后一次生效，中间的更新动作意义并不大，我们可以把缓存删除，等待再次查询时，将缓存中的数据加载出来

删除缓存还是更新缓存？
- 更新缓存：每次更新数据库都更新缓存，无效写操作较多
- 删除缓存：更新数据库时让缓存失效，查询时再更新缓存
如何保证缓存与数据库的操作的同时成功或失败？
- 单体系统，将缓存与数据库操作放在一个事务
- 分布式系统，利用TCC等分布式事务方案

应该具体操作缓存还是操作数据库，我们应当是先操作数据库，再删除缓存，原因在于，如果你选择第一种方案，在两个线程并发来访问时，假设线程1先来，他先把缓存删了，此时线程2过来，他查询缓存数据并不存在，此时他写入缓存，当他写入缓存后，线程1再执行更新动作时，实际上写入的就是旧的数据，新的数据被旧数据覆盖了。

先操作缓存还是先操作数据库？
- 先删除缓存，再操作数据库
- 先操作数据库，再删除缓存

3.2.4实现商铺和缓存与数据库双写一致

核心思路如下：

修改ShopController中的业务逻辑，满足下面的需求：

根据id查询店铺时，如果缓存未命中，则查询数据库，将数据库结果写入缓存，并设置超时时间

根据id修改店铺时，先修改数据库，再删除缓存

修改重点代码1：修改ShopServiceImpl的queryById方法

设置redis缓存时添加过期时间

@Overridepublic Result qureyById(Long id) {String key =CACHE_SHOP_KEY + id;//1.从redis查询商铺缓存String shopJson = stringRedisTemplate.opsForValue().get(key);//2.判断是否存在if(StrUtil.isNotBlank(shopJson)){//3.存在，返回Shop shop = JSONUtil.toBean(shopJson, Shop.class);return Result.ok(shop);}//判断命中是否是空值if(shopJson != null){//返回一个错误信息return Result.fail("店铺信息不存在!");}//4.不存在，根据id查询数据库Shop shop = getById(id);if(shop == null){//将空值写入redisstringRedisTemplate.opsForValue().set(key,"",CACHE_NULL_TTL, TimeUnit.MINUTES);//5.不存在，返回错误return Result.fail("店铺不存在！");}//6.存在.写入redisstringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(shop),CACHE_SHOP_TTL, TimeUnit.MINUTES);//7.返回return Result.ok(shop);}@Override@Transactionalpublic Result update(Shop shop) {Long id = shop.getId();if(id == null){return Result.fail("店铺id不能为空");}//1.更新数据库updateById(shop);//2.删除缓存stringRedisTemplate.delete(CACHE_SHOP_KEY + shop.getId());return Result.ok();}

**代码分析：**通过之前的淘汰，我们确定了采用删除策略，来解决双写问题，当我们修改了数据之后，然后把缓存中的数据进行删除，查询时发现缓存中没有数据，则会从mysql中加载最新的数据，从而避免数据库和缓存不一致的问题

3.2.5缓存穿透问题的解决思路

缓存穿透：缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库。

常见的解决方案有两种：

缓存空对象
- 优点：实现简单，维护方便
- 缺点：
  - 额外的内存消耗
  - 可能造成短期的不一致:在空对象存在时间内，向数据库增加了此店铺，导致增加后查询任为空。
布隆过滤
- 优点：内存占用较少，没有多余key
- 缺点：
  - 实现复杂
  - 存在误判可能

**缓存空对象思路分析：**当我们客户端访问不存在的数据时，先请求redis，但是此时redis中没有数据，此时会访问到数据库，但是数据库中也没有数据，这个数据穿透了缓存，直击数据库，我们都知道数据库能够承载的并发不如redis这么高，如果大量的请求同时过来访问这种不存在的数据，这些请求就都会访问到数据库，简单的解决方案就是哪怕这个数据在数据库中也不存在，我们也把这个数据存入到redis中去，这样，下次用户过来访问这个不存在的数据，那么在redis中也能找到这个数据就不会进入到数据库了

**布隆过滤：**布隆过滤器其实采用的是哈希思想来解决这个问题，通过一个庞大的二进制数组，走哈希思想去判断当前这个要查询的这个数据是否存在，如果布隆过滤器判断存在，则放行，这个请求会去访问redis，哪怕此时redis中的数据过期了，但是数据库中一定存在这个数据，在数据库中查询出来这个数据后，再将其放入到redis中，

假设布隆过滤器判断这个数据不存在，则直接返回

这种方式优点在于节约内存空间，存在误判，误判原因在于：布隆过滤器走的是哈希思想，只要哈希思想，就可能存在哈希冲突

3.2.6编码解决商品查询的缓存穿透问题：

核心思路如下：

在原来的逻辑中，我们如果发现这个数据在mysql中不存在，直接就返回404了，这样是会存在缓存穿透问题的

现在的逻辑中：如果这个数据不存在，我们不会返回404 ，还是会把这个数据写入到Redis中，并且将value设置为空，欧当再次发起查询时，我们如果发现命中之后，判断这个value是否是null，如果是null，则是之前写入的数据，证明是缓存穿透数据，如果不是，则直接返回数据。

小总结：

缓存穿透产生的原因是什么？

用户请求的数据在缓存中和数据库中都不存在，不断发起这样的请求，给数据库带来巨大压力

缓存穿透的解决方案有哪些？

缓存null值
- 上面已实现
布隆过滤
增强id的复杂度，避免被猜测id规律
- 对店铺id做随机数，可以以时间转换后的数据为id
做好数据的基础格式校验
加强用户权限校验
做好热点参数的限流

3.2.7缓存雪崩问题及解决思路

缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。

解决方案：

给不同的Key的TTL添加随机值
利用Redis集群提高服务的可用性
给缓存业务添加降级限流策略
给业务添加多级缓存

3.2.82.8 缓存击穿问题及解决思路

缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。

常见的解决方案有两种：

互斥锁
逻辑过期

逻辑分析：假设线程1在查询缓存之后，本来应该去查询数据库，然后把这个数据重新加载到缓存的，此时只要线程1走完这个逻辑，其他线程就都能从缓存中加载这些数据了，但是假设在线程1没有走完的时候，后续的线程2，线程3，线程4同时过来访问当前这个方法，那么这些线程都不能从缓存中查询到数据，那么他们就会同一时刻来访问查询缓存，都没查到，接着同一时间去访问数据库，同时的去执行数据库代码，对数据库访问压力过大

解决方案一、使用锁来解决：

因为锁能实现互斥性。假设线程过来，只能一个人一个人的来访问数据库，从而避免对于数据库访问压力过大，但这也会影响查询的性能，因为此时会让查询的性能从并行变成了串行，我们可以采用tryLock方法 + double check来解决这样的问题。

假设现在线程1过来访问，他查询缓存没有命中，但是此时他获得到了锁的资源，那么线程1就会一个人去执行逻辑，假设现在线程2过来，线程2在执行过程中，并没有获得到锁，那么线程2就可以进行到休眠，直到线程1把锁释放后，线程2获得到锁，然后再来执行逻辑，此时就能够从缓存中拿到数据了。

解决方案二、逻辑过期方案

方案分析：我们之所以会出现这个缓存击穿问题，主要原因是在于我们对key设置了过期时间，假设我们不设置过期时间，其实就不会有缓存击穿的问题，但是不设置过期时间，这样数据不就一直占用我们内存了吗，我们可以采用逻辑过期方案。

我们把过期时间设置在 redis的value中，注意：这个过期时间并不会直接作用于redis，而是我们后续通过逻辑去处理。假设线程1去查询缓存，然后从value中判断出来当前的数据已经过期了，此时线程1去获得互斥锁，那么其他线程会进行阻塞，获得了锁的线程他会开启一个线程去进行以前的重构数据的逻辑，直到新开的线程完成这个逻辑后，才释放锁，而线程1直接进行返回，假设现在线程3过来访问，由于线程线程2持有着锁，所以线程3无法获得锁，线程3也直接返回数据，只有等到新开的线程2把重建数据构建完后，其他线程才能走返回正确的数据。

这种方案巧妙在于，异步的构建缓存，缺点在于在构建完缓存之前，返回的都是脏数据。

进行对比

**互斥锁方案：**由于保证了互斥性，所以数据一致，且实现简单，因为仅仅只需要加一把锁而已，也没其他的事情需要操心，所以没有额外的内存消耗，缺点在于有锁就有死锁问题的发生，且只能串行执行性能肯定受到影响

逻辑过期方案： 线程读取过程中不需要等待，性能好，有一个额外的线程持有锁去进行重构数据，但是在重构数据完成前，其他的线程只能返回之前的数据，且实现起来麻烦

3.2.9 利用互斥锁解决缓存击穿问题

核心思路：相较于原来从缓存中查询不到数据后直接查询数据库而言，现在的方案是进行查询之后，如果从缓存没有查询到数据，则进行互斥锁的获取，获取互斥锁后，判断是否获得到了锁，如果没有获得到，则休眠，过一会再进行尝试，直到获取到锁为止，才能进行查询

如果获取到了锁的线程，再去进行查询，查询后将数据写入redis，再释放锁，返回数据，利用互斥锁就能保证只有一个线程去执行操作数据库的逻辑，防止缓存击穿

操作锁的代码：

核心思路就是利用redis的setnx方法来表示获取锁，该方法含义是redis中如果没有这个key，则插入成功，返回1，在stringRedisTemplate中返回true，如果有这个key则插入失败，则返回0，在stringRedisTemplate返回false，我们可以通过true，或者是false，来表示是否有线程成功插入key，成功插入的key的线程我们认为他就是获得到锁的线程。

private boolean tryLock(String key) {Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.SECONDS);return BooleanUtil.isTrue(flag);
}private void unlock(String key) {stringRedisTemplate.delete(key);
}

操作代码：

/*** 互斥锁解决缓存击穿* @param id* @return*/public Shop queryWithMutex(Long id){String key =CACHE_SHOP_KEY + id;//1.从redis查询商铺缓存String shopJson = stringRedisTemplate.opsForValue().get(key);//2.判断是否存在if(StrUtil.isNotBlank(shopJson)){//2.1.存在，返回return JSONUtil.toBean(shopJson, Shop.class);}//3.判断命中是否是空值if(shopJson != null){//3.1返回一个错误信息return null;}//4.实现缓存重建//4.1获取互斥锁String lockKey = LOCK_SHOP_KEY+id;Shop shop = null;try {Boolean isLock = tryLock(lockKey);//4.2判断是否获取成功if(!isLock){//4.3失败,则休眠并重试Thread.sleep(50);//4.4尝试获取锁queryWithMutex(id);}//4.5.从redis查询商铺缓存shopJson = stringRedisTemplate.opsForValue().get(key);//5.二次判断是否存在if(StrUtil.isNotBlank(shopJson)){//这里不释放锁，因为finally一定会执行//5.1.存在，返回return JSONUtil.toBean(shopJson, Shop.class);}//6.拿到锁且缓存无数据，根据id查询数据库shop = getById(id);//模拟重建的延时Thread.sleep(200);if(shop == null){//将空值写入redisstringRedisTemplate.opsForValue().set(key,"",CACHE_NULL_TTL, TimeUnit.MINUTES);//5.不存在，返回错误return null;}//6.存在.写入redisstringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(shop),CACHE_SHOP_TTL, TimeUnit.MINUTES);} catch (InterruptedException e) {throw new RuntimeException(e);}finally {//7.释放互斥锁unLock(lockKey);}//7.返回return shop;}

3.2.10利用逻辑过期解决缓存击穿问题

需求：修改根据id查询商铺的业务，基于逻辑过期方式来解决缓存击穿问题

思路分析：当用户开始查询redis时，判断是否命中，如果没有命中则直接返回空数据，不查询数据库，而一旦命中后，将value取出，判断value中的过期时间是否满足，如果没有过期，则直接返回redis中的数据，如果过期，则在开启独立线程后直接返回之前的数据，独立线程去重构数据，重构完成后释放互斥锁。

如果封装数据：因为现在redis中存储的数据的value需要带上过期时间，此时要么你去修改原来的实体类，要么你

步骤一、

新建一个实体类，我们采用第二个方案，这个方案，对原来代码没有侵入性。

@Data
public class RedisData {private LocalDateTime expireTime;private Object data;
}

步骤二、

在ShopServiceImpl 新增此方法，利用单元测试进行缓存预热

/*** 设置redis数据逻辑过期时间* @param id* @param expireSeconds*/public void saveShop2Redis(Long id,Long expireSeconds){//1.查询店铺数据Shop shop = getById(id);//2.封装逻辑过期时间RedisData redisData = new RedisData();redisData.setData(shop);redisData.setExpireTime(LocalDateTime.now().plusSeconds(expireSeconds));//3.写入rdisstringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY+id,JSONUtil.toJsonStr(redisData));}

在测试类中

    @Testvoid testSaveShop(){shopService.saveShop2Redis(1L,10L);}

步骤三：正式代码

ShopServiceImpl

    //线程池private static final ExecutorService CACHE_REBULD_EXECUTOR = Executors.newFixedThreadPool(10);/*** 用逻辑过期解决缓存击穿* @param id* @return*/public Shop queryWithLogicalExpir(Long id){String key =CACHE_SHOP_KEY + id;//1.从redis查询商铺缓存String shopJson = stringRedisTemplate.opsForValue().get(key);//2.判断是否存在if(StrUtil.isBlank(shopJson)){//3.不存在，返回return null;}//4.命中，需要把json反序列化为对象RedisData redisData = JSONUtil.toBean(shopJson, RedisData.class);//由于在redis中data为Object类型，所以反序列化时会转成JSONObject类型，所以需要在反序列化一次//JSONObject data = (JSONObject)redisData.getData();Shop shop = JSONUtil.toBean((JSONObject) redisData.getData(), Shop.class);LocalDateTime expireTime = redisData.getExpireTime();//5判断是否过期if(expireTime.isAfter(LocalDateTime.now())){return shop;}//5.2已过期，需要缓存重建//6.缓存重建//6.1获取互斥锁String lockKey = LOCK_SHOP_KEY+id;Boolean isLock = tryLock(lockKey);//6.2是否获取锁成功if(isLock){shopJson = stringRedisTemplate.opsForValue().get(key);//2.再次判断是否存在if(StrUtil.isNotBlank(shopJson)){//3.存在，返回return JSONUtil.toBean((JSONObject)JSONUtil.toBean(shopJson,RedisData.class).getData(),Shop.class);}//6.3成功，开启独立线程实现缓存重建CACHE_REBULD_EXECUTOR.submit(()-> {try {//重建缓存this.saveShop2Redis(id,30L);} catch (Exception e) {throw new RuntimeException(e);}finally {//释放锁unLock(lockKey);}});}//6.4失败，返回过期数据return shop;}

3.2.11封装Redis工具类

基于StringRedisTemplate封装一个缓存工具类，满足下列需求：

方法1：将任意Java对象序列化为json并存储在string类型的key中，并且可以设置TTL过期时间
方法2：将任意Java对象序列化为json并存储在string类型的key中，并且可以设置逻辑过期时间，用于处理缓

存击穿问题

方法3：根据指定的key查询缓存，并反序列化为指定类型，利用缓存空值的方式解决缓存穿透问题
方法4：根据指定的key查询缓存，并反序列化为指定类型，需要利用逻辑过期解决缓存击穿问题

将逻辑进行封装

package com.hmdp.utils;import cn.hutool.core.util.BooleanUtil;
import cn.hutool.core.util.StrUtil;
import cn.hutool.json.JSONObject;
import cn.hutool.json.JSONUtil;
import com.hmdp.entity.Shop;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Component;import javax.annotation.Resource;
import java.time.LocalDateTime;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import java.util.function.Function;import static com.hmdp.utils.RedisConstants.*;/*** @BelongsProject: hm-dianping* @BelongsPackage: com.hmdp.utils* @Author: wh* @CreateTime: 2022-10-25  20:25* @Description: TODO* @Version: 1.0*/
@Slf4j
@Component
public class CacheClient {private final StringRedisTemplate stringRedisTemplate;public CacheClient(StringRedisTemplate stringRedisTemplate){this.stringRedisTemplate = stringRedisTemplate;}/*** 将类转换成String类型的json存入redis，并设置过期时间* @param key  键* @param value 值* @param time  时间* @param unit  时间类型*/public void set(String key ,Object value, Long time, TimeUnit unit){stringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(value),time,unit);}/*** 将类转换成String类型的json存入redis，并设置逻辑过期时间* @param key    键* @param value 值* @param time 时间* @param unit 时间类型*/public void setWithLogicalExpire(String key, Object value, Long time, TimeUnit unit){//设置逻辑过期时间RedisData redisData = new RedisData();redisData.setData(value);redisData.setExpireTime(LocalDateTime.now().plusSeconds(unit.toSeconds(time)));//写入RedisstringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(redisData));}/*** 查询使用redis做缓存并解决缓存穿透* @param keyPrefix* @param id* @param type* @param dbFallback* @param time* @param unit* @return* @param <R>* @param <ID>*/public <R,ID> R queryWithPassThrough(String keyPrefix, ID id, Class<R> type, Function<ID,R> dbFallback, Long time, TimeUnit unit){String key =CACHE_SHOP_KEY + id;//1.从redis查询商铺缓存String json = stringRedisTemplate.opsForValue().get(key);//2.判断是否存在if(StrUtil.isNotBlank(json)){//3.存在，返回return JSONUtil.toBean(json, type);}//判断命中是否是空值if(json != null){//返回一个错误信息return null;}//4.不存在，根据id查询数据库R r = dbFallback.apply(id);if(r == null){//将空值写入redisstringRedisTemplate.opsForValue().set(key,"",CACHE_NULL_TTL, TimeUnit.MINUTES);//5.不存在，返回错误return null;}//6.存在.写入redisthis.set(key,r,time,unit);//7.返回return r;}private static final ExecutorService CACHE_REBULD_EXECUTOR = Executors.newFixedThreadPool(10);/*** 查询时，利用逻辑过期时间解决缓存击穿,前提是数据已经在rdis中* @param keyPrefix* @param lockPrefix* @param id* @param type* @param dbFallback* @param time* @param unit* @return* @param <R>* @param <ID>*/public <R,ID> R queryWithLogicalExpir(String keyPrefix,String lockPrefix ,ID id,Class<R> type,Function<ID,R> dbFallback,Long time, TimeUnit unit){//获取键String key =keyPrefix + id;//1.从redis查询商铺缓存String Json = stringRedisTemplate.opsForValue().get(key);//2.判断是否存在if(StrUtil.isBlank(Json)){//3.不存在，直接返回。return null;}//4.命中，需要把json反序列化为对象RedisData redisData = JSONUtil.toBean(Json, RedisData.class);//由于在redis中data为Object类型，所以反序列化时会转成JSONObject类型，所以需要在反序列化一次//JSONObject data = (JSONObject)redisData.getData();R r = JSONUtil.toBean((JSONObject) redisData.getData(),type);LocalDateTime expireTime = redisData.getExpireTime();//5判断是否过期if(expireTime.isAfter(LocalDateTime.now())){//没过期return r;}//5.2已过期，需要缓存重建//6.缓存重建//6.1获取互斥锁String lockKey = lockPrefix+id;Boolean isLock = tryLock(lockKey);//6.2是否获取锁成功if(isLock){Json = stringRedisTemplate.opsForValue().get(key);//2.再次判断是否存在if(StrUtil.isNotBlank(Json)){//3.存在，返回return JSONUtil.toBean((JSONObject)JSONUtil.toBean(Json,RedisData.class).getData(),type);}//6.3成功，开启独立线程实现缓存重建CACHE_REBULD_EXECUTOR.submit(()-> {try {//查询数据库R r1 = dbFallback.apply(id);//重建缓存this.setWithLogicalExpire(key,r,time,unit);} catch (Exception e) {throw new RuntimeException(e);}finally {//释放锁unLock(lockKey);}});}//6.4失败，返回过期数据return r;}/*** 获取锁* @param key* @return*/private Boolean tryLock(String key){Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.MINUTES);return BooleanUtil.isTrue(flag);}/*** 释放锁* @param key*/private void unLock(String key){stringRedisTemplate.delete(key);}/*** 查询时，互斥锁解决缓存击穿* @param keyPrefix* @param lockPrefix* @param id* @param type* @param dbFallback* @param time* @param unit* @return* @param <R>* @param <ID>*/public <R,ID> R queryWithMutex(String keyPrefix,String lockPrefix ,ID id,Class<R> type,Function<ID,R> dbFallback,Long time, TimeUnit unit){String key =keyPrefix + id;//1.从redis查询商铺缓存String Json = stringRedisTemplate.opsForValue().get(key);//2.判断是否存在if(StrUtil.isNotBlank(Json)){//2.1.存在，返回return JSONUtil.toBean(Json, type);}//3.判断命中是否是空值if(Json != null){//3.1返回一个错误信息return null;}//4.实现缓存重建//4.1获取互斥锁String lockKey = lockPrefix+id;R r = null;try {Boolean isLock = tryLock(lockKey);//4.2判断是否获取成功if(!isLock){//4.3失败,则休眠并重试Thread.sleep(50);//4.4再去尝试获取锁queryWithMutex(keyPrefix,lockPrefix,id,type,dbFallback,time,unit);}//4.5.从redis查询商铺缓存Json = stringRedisTemplate.opsForValue().get(key);//5.判断是否存在if(StrUtil.isNotBlank(Json)){//这里不释放锁，因为finally一定会执行//5.1.存在，返回return JSONUtil.toBean(Json, type);}//6.拿到锁且缓存无数据，根据id查询数据库r = dbFallback.apply(id);//模拟重建的延时Thread.sleep(200);if(r == null){//将空值写入redisstringRedisTemplate.opsForValue().set(key,"",CACHE_NULL_TTL, TimeUnit.MINUTES);//5.不存在，返回错误return null;}//6.存在.写入redisstringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(r),time, unit);} catch (InterruptedException e) {throw new RuntimeException(e);}finally {//7.释放互斥锁unLock(lockKey);}//7.返回return r;}}

相对比之前的代码，也做了一些精修，之前有部分内容没考虑到位，此时shopserviceImpl中查询店铺就可以直接调用这些方法了，以后的查询需要用到redis也可以直接用。

3.3优惠卷秒杀

3.3.1全局唯一ID

每个店铺都可以发布优惠券：

当用户抢购时，就会生成订单并保存到tb_voucher_order这张表中，而订单表如果使用数据库自增ID就存在一些问题：

id的规律性太明显
受单表数据量的限制

场景分析：如果我们的id具有太明显的规则，用户或者说商业对手很容易猜测出来我们的一些敏感信息，比如商城在一天时间内，卖出了多少单，这明显不合适。

场景分析二：随着我们商城规模越来越大，mysql的单表的容量不宜超过500W，数据量过大之后，我们要进行拆库拆表，但拆分表了之后，他们从逻辑上讲他们是同一张表，所以他们的id是不能一样的，于是乎我们需要保证id的唯一性。

全局ID生成器，是一种在分布式系统下用来生成全局唯一ID的工具，一般要满足下列特性：

为了增加ID的安全性，我们可以不直接使用Redis自增的数值，而是拼接一些其它信息：

ID的组成部分：符号位：1bit，永远为0

时间戳：31bit，以秒为单位，可以使用69年

序列号：32bit，秒内的计数器，支持每秒产生2^32个不同ID

3.3.2Redis实现全局唯一Id

import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Component;import java.time.LocalDateTime;
import java.time.ZoneOffset;
import java.time.format.DateTimeFormatter;/*** redis生成唯一id* @BelongsProject: hm-dianping* @BelongsPackage: com.hmdp.utils* @Author: wh* @CreateTime: 2022-10-26  14:05* @Description: TODO* @Version: 1.0*/
@Component
public class RedisIdWorker {/*** 开始时间戳 2022 01 01*/private static final long BGIN_TIMESTAMP = 1640995200L;/*** 序列号的位数*/private static final int COUNT_BITS = 32;//redisprivate StringRedisTemplate stringRedisTemplate;//初始化redispublic RedisIdWorker(StringRedisTemplate redisTemplate) {this.stringRedisTemplate = redisTemplate;}/*** redis生成唯一id* @param kryPrefix* @return*/public long nextId(String kryPrefix){//1.生成时间戳LocalDateTime now = LocalDateTime.now();long nowSecond = now.toEpochSecond(ZoneOffset.UTC);long timestamp = nowSecond-BGIN_TIMESTAMP;//2.生成序列号//2.1获取当前日期，精确到天String date = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));//2.2自增长 reids存的是订单数long count = stringRedisTemplate.opsForValue().increment("icr:" + kryPrefix + ":" + date);//3.拼接并返回//      下单时间减去特定时间点  左移32之后 后面32位存订单数return timestamp << COUNT_BITS | count;}
}

测试类

知识小贴士：关于countdownlatch

countdownlatch名为信号枪：主要的作用是同步协调在多线程的等待与唤醒问题

我们如果没有CountDownLatch ，那么由于程序是异步的，当异步程序没有执行完时，主线程就已经执行完了，然后我们期望的是分线程全部走完之后，主线程再走，所以我们此时需要使用到CountDownLatch

CountDownLatch 中有两个最重要的方法

1、countDown

2、await

await 方法是阻塞方法，我们担心分线程没有执行完时，main线程就先执行，所以使用await可以让main线程阻塞，那么什么时候main线程不再阻塞呢？当CountDownLatch 内部维护的变量变为0时，就不再阻塞，直接放行，那么什么时候CountDownLatch 维护的变量变为0 呢，我们只需要调用一次countDown ，内部变量就减少1，我们让分线程和变量绑定，执行完一个分线程就减少一个变量，当分线程全部走完，CountDownLatch 维护的变量就是0，此时await就不再阻塞，统计出来的时间也就是所有分线程执行完后的时间。

@Test
void testIdWorker() throws InterruptedException {CountDownLatch latch = new CountDownLatch(300);
```Runnable task = () -> {for (int i = 0; i < 100; i++) {long id = redisIdWorker.nextId("order");System.out.println("id = " + id);}latch.countDown();};long begin = System.currentTimeMillis();for (int i = 0; i < 300; i++) {es.submit(task);}latch.await();long end = System.currentTimeMillis();System.out.println("time = " + (end - begin));
}

3.3.3添加优惠卷

每个店铺都可以发布优惠券，分为平价券和特价券。平价券可以任意购买，而特价券需要秒杀抢购：

tb_voucher：优惠券的基本信息，优惠金额、使用规则等
tb_seckill_voucher：优惠券的库存、开始抢购时间，结束抢购时间。特价优惠券才需要填写这些信息

平价卷由于优惠力度并不是很大，所以是可以任意领取

而代金券由于优惠力度大，所以像第二种卷，就得限制数量，从表结构上也能看出，特价卷除了具有优惠卷的基本信息以外，还具有库存，抢购时间，结束时间等等字段

**新增普通卷代码： **VoucherController

@PostMapping
public Result addVoucher(@RequestBody Voucher voucher) {voucherService.save(voucher);return Result.ok(voucher.getId());
}

新增秒杀卷代码：

VoucherController

@PostMapping("seckill")
public Result addSeckillVoucher(@RequestBody Voucher voucher) {voucherService.addSeckillVoucher(voucher);return Result.ok(voucher.getId());
}

VoucherServiceImpl

@Override
@Transactional
public void addSeckillVoucher(Voucher voucher) {// 保存优惠券save(voucher);// 保存秒杀信息SeckillVoucher seckillVoucher = new SeckillVoucher();seckillVoucher.setVoucherId(voucher.getId());seckillVoucher.setStock(voucher.getStock());seckillVoucher.setBeginTime(voucher.getBeginTime());seckillVoucher.setEndTime(voucher.getEndTime());seckillVoucherService.save(seckillVoucher);// 保存秒杀库存到Redis中stringRedisTemplate.opsForValue().set(SECKILL_STOCK_KEY + voucher.getId(), voucher.getStock().toString());
}

3.3.4实现秒杀下单

下单核心思路：当我们点击抢购时，会触发右侧的请求，我们只需要编写对应的controller即可

秒杀下单应该思考的内容：

下单时需要判断两点：

秒杀是否开始或结束，如果尚未开始或已经结束则无法下单
库存是否充足，不足则无法下单

下单核心逻辑分析：

当用户开始进行下单，我们应当去查询优惠卷信息，查询到优惠卷信息，判断是否满足秒杀条件

比如时间是否充足，如果时间充足，则进一步判断库存是否足够，如果两者都满足，则扣减库存，创建订单，然后返回订单id，如果有一个条件不满足则直接结束。

VoucherOrderServiceImpl

@Override
public Result seckillVoucher(Long voucherId) {// 1.查询优惠券SeckillVoucher voucher = seckillVoucherService.getById(voucherId);// 2.判断秒杀是否开始if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {// 尚未开始return Result.fail("秒杀尚未开始！");}// 3.判断秒杀是否已经结束if (voucher.getEndTime().isBefore(LocalDateTime.now())) {// 尚未开始return Result.fail("秒杀已经结束！");}// 4.判断库存是否充足if (voucher.getStock() < 1) {// 库存不足return Result.fail("库存不足！");}//5，扣减库存boolean success = seckillVoucherService.update().setSql("stock= stock -1").eq("voucher_id", voucherId).update();if (!success) {//扣减库存return Result.fail("库存不足！");}//6.创建订单VoucherOrder voucherOrder = new VoucherOrder();// 6.1.订单idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);// 6.2.用户idLong userId = UserHolder.getUser().getId();voucherOrder.setUserId(userId);// 6.3.代金券idvoucherOrder.setVoucherId(voucherId);save(voucherOrder);return Result.ok(orderId);}

3.3.5库存超卖问题分析

有关超卖问题分析：在我们原有代码中是这么写的

 if (voucher.getStock() < 1) {// 库存不足return Result.fail("库存不足！");}//5，扣减库存boolean success = seckillVoucherService.update().setSql("stock= stock -1").eq("voucher_id", voucherId).update();if (!success) {//扣减库存return Result.fail("库存不足！");}

假设线程1过来查询库存，判断出来库存大于1，正准备去扣减库存，但是还没有来得及去扣减，此时线程2过来，线程2也去查询库存，发现这个数量一定也大于1，那么这两个线程都会去扣减库存，最终多个线程相当于一起去扣减库存，此时就会出现库存的超卖问题。

超卖问题是典型的多线程安全问题，针对这一问题的常见解决方案就是加锁：而对于加锁，我们通常有两种解决方案：见下图：

悲观锁：

悲观锁可以实现对于数据的串行化执行，比如syn，和lock都是悲观锁的代表，同时，悲观锁中又可以再细分为公平锁，非公平锁，可重入锁，等等

乐观锁：

乐观锁：会有一个版本号，每次操作数据会对版本号+1，再提交回数据时，会去校验是否比之前的版本大1 ，如果大1 ，则进行操作成功，这套机制的核心逻辑在于，如果在操作过程中，版本号只比原来大1 ，那么就意味着操作过程中没有人对他进行过修改，他的操作就是安全的，如果不大1，则数据被修改过，当然乐观锁还有一些变种的处理方式比如cas

乐观锁的典型代表：就是cas，利用cas进行无锁化机制加锁，var5 是操作前读取的内存值，while中的var1+var2 是预估值，如果预估值 == 内存值，则代表中间没有被人修改过，此时就将新值去替换内存值

其中do while 是为了在操作失败时，再次进行自旋操作，即把之前的逻辑再操作一次。

int var5;
do {var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));return var5;

课程中的使用方式：

课程中的使用方式是没有像cas一样带自旋的操作，也没有对version的版本号+1 ，他的操作逻辑是在操作时，对版本号进行+1 操作，然后要求version 如果是1 的情况下，才能操作，那么第一个线程在操作后，数据库中的version变成了2，但是他自己满足version=1 ，所以没有问题，此时线程2执行，线程2 最后也需要加上条件version =1 ，但是现在由于线程1已经操作过了，所以线程2，操作时就不满足version=1 的条件了，所以线程2无法执行成功

3.3.6乐观锁解决超卖问题

修改代码方案一、

VoucherOrderServiceImpl 在扣减库存时，改为：

boolean success = seckillVoucherService.update().setSql("stock= stock -1") //set stock = stock -1.eq("voucher_id", voucherId).eq("stock",voucher.getStock()).update(); //where id = ？ and stock = ?

以上逻辑的核心含义是：只要我扣减库存时的库存和之前我查询到的库存是一样的，就意味着没有人在中间修改过库存，那么此时就是安全的，但是以上这种方式通过测试发现会有很多失败的情况，失败的原因在于：在使用乐观锁过程中假设100个线程同时都拿到了100的库存，然后大家一起去进行扣减，但是100个人中只有1个人能扣减成功，其他的人在处理时，他们在扣减时，库存已经被修改过了，所以此时其他线程都会失败

修改代码方案二、

之前的方式要修改前后都保持一致，但是这样我们分析过，成功的概率太低，所以我们的乐观锁需要变一下，改成stock大于0 即可

boolean success = seckillVoucherService.update().setSql("stock= stock -1").eq("voucher_id", voucherId).update().gt("stock",0); //where id = ? and stock > 0

按照乐观锁的概念，这好像不算乐观锁了。你就说好不好使吧！

知识小扩展：

针对cas中的自旋压力过大，我们可以使用Longaddr这个类去解决

Java8 提供的一个对AtomicLong改进后的一个类，LongAdder

大量线程并发更新一个原子性的时候，天然的问题就是自旋，会导致并发性问题，当然这也比我们直接使用syn来的好

所以利用这么一个类，LongAdder来进行优化

如果获取某个值，则会对cell和base的值进行递增，最后返回一个完整的值

3.3.7优惠券秒杀-一人一单

需求：修改秒杀业务，要求同一个优惠券，一个用户只能下一单

现在的问题在于：

优惠卷是为了引流，但是目前的情况是，一个人可以无限制的抢这个优惠卷，所以我们应当增加一层逻辑，让一个用户只能下一个单，而不是让一个用户下多个单

具体操作逻辑如下：比如时间是否充足，如果时间充足，则进一步判断库存是否足够，然后再根据优惠卷id和用户id查询是否已经下过这个订单，如果下过这个订单，则不再下单，否则进行下单

VoucherOrderServiceImpl

初步代码：增加一人一单逻辑

@Override
public Result seckillVoucher(Long voucherId) {// 1.查询优惠券SeckillVoucher voucher = seckillVoucherService.getById(voucherId);// 2.判断秒杀是否开始if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {// 尚未开始return Result.fail("秒杀尚未开始！");}// 3.判断秒杀是否已经结束if (voucher.getEndTime().isBefore(LocalDateTime.now())) {// 尚未开始return Result.fail("秒杀已经结束！");}// 4.判断库存是否充足if (voucher.getStock() < 1) {// 库存不足return Result.fail("库存不足！");}// 5.一人一单逻辑// 5.1.用户idLong userId = UserHolder.getUser().getId();int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();// 5.2.判断是否存在if (count > 0) {// 用户已经购买过了return Result.fail("用户已经购买过一次！");}//6，扣减库存boolean success = seckillVoucherService.update().setSql("stock= stock -1").eq("voucher_id", voucherId).update();if (!success) {//扣减库存return Result.fail("库存不足！");}//7.创建订单VoucherOrder voucherOrder = new VoucherOrder();// 7.1.订单idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);voucherOrder.setUserId(userId);// 7.3.代金券idvoucherOrder.setVoucherId(voucherId);save(voucherOrder);return Result.ok(orderId);}

**存在问题：**现在的问题还是和之前一样，并发过来，查询数据库，都不存在订单，所以我们还是需要加锁，但是乐观锁比较适合更新数据，而现在是插入数据，所以我们需要使用悲观锁操作

**注意：**在这里提到了非常多的问题，我们需要慢慢的来思考，首先我们的初始方案是封装了一个createVoucherOrder方法，同时为了确保他线程安全，在方法上添加了一把synchronized 锁

@Transactional
public synchronized Result createVoucherOrder(Long voucherId) {Long userId = UserHolder.getUser().getId();// 5.1.查询订单int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();// 5.2.判断是否存在if (count > 0) {// 用户已经购买过了return Result.fail("用户已经购买过一次！");}// 6.扣减库存boolean success = seckillVoucherService.update().setSql("stock = stock - 1") // set stock = stock - 1.eq("voucher_id", voucherId).gt("stock", 0) // where id = ? and stock > 0.update();if (!success) {// 扣减失败return Result.fail("库存不足！");}// 7.创建订单VoucherOrder voucherOrder = new VoucherOrder();// 7.1.订单idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);// 7.2.用户idvoucherOrder.setUserId(userId);// 7.3.代金券idvoucherOrder.setVoucherId(voucherId);save(voucherOrder);// 7.返回订单idreturn Result.ok(orderId);
}

，但是这样添加锁，锁的粒度太粗了，在使用锁过程中，控制锁粒度 是一个非常重要的事情，因为如果锁的粒度太大，会导致每个线程进来都会锁住，所以我们需要去控制锁的粒度，以下这段代码需要修改为：
intern() 这个方法是从常量池中拿到数据，如果我们直接使用userId.toString() 他拿到的对象实际上是不同的对象，new出来的对象，我们使用锁必须保证锁必须是同一把，所以我们需要使用intern()方法

@Transactional
public  Result createVoucherOrder(Long voucherId) {Long userId = UserHolder.getUser().getId();synchronized(userId.toString().intern()){// 5.1.查询订单int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();// 5.2.判断是否存在if (count > 0) {// 用户已经购买过了return Result.fail("用户已经购买过一次！");}// 6.扣减库存boolean success = seckillVoucherService.update().setSql("stock = stock - 1") // set stock = stock - 1.eq("voucher_id", voucherId).gt("stock", 0) // where id = ? and stock > 0.update();if (!success) {// 扣减失败return Result.fail("库存不足！");}// 7.创建订单VoucherOrder voucherOrder = new VoucherOrder();// 7.1.订单idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);// 7.2.用户idvoucherOrder.setUserId(userId);// 7.3.代金券idvoucherOrder.setVoucherId(voucherId);save(voucherOrder);// 7.返回订单idreturn Result.ok(orderId);}
}

但是以上代码还是存在问题，问题的原因在于当前方法被spring的事务控制，如果你在方法内部加锁，可能会导致当前方法事务还没有提交，但是锁已经释放也会导致问题，所以我们选择将当前方法整体包裹起来，确保事务不会出现问题：如下：

在seckillVoucher 方法中，添加以下逻辑，这样就能保证事务的特性，同时也控制了锁的粒度

但是以上做法依然有问题，因为你调用的方法，其实是this.的方式调用的，事务想要生效，还得利用代理来生效，所以这个地方，我们需要获得原始的事务对象，来操作事务

导包

        <dependency><groupId>org.aspectj</groupId><artifactId>aspectjweaver</artifactId></dependency>

开启注解驱动

修改后的代码：

@Service
public class VoucherOrderServiceImpl extends ServiceImpl<VoucherOrderMapper, VoucherOrder> implements IVoucherOrderService {@Resourceprivate ISeckillVoucherService seckillVoucherService;@Resourceprivate RedisIdWorker redisIdWorker;@Override/*** 实现秒杀并保证一人一单*/public Result seckillVoucher(Long voucherId) {//1.查询优惠劵SeckillVoucher voucher = seckillVoucherService.getById(voucherId);//2.判断秒杀是否开始if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {//尚未开始return Result.fail("秒杀尚未开始");}//3.判断秒杀是否结束if (voucher.getEndTime().isBefore(LocalDateTime.now())) {//尚未开始return Result.fail("秒杀已经结束");}//4.判断库存是否充足if(voucher.getStock() < 1){//库存不足return Result.fail("库存不足！");}Long userId = UserHolder.getUser().getId();//intern()去字符串常量池找，有就返回，没有就创，保证了id唯一synchronized(userId.toString().intern()) {//获取代理对象（事务）IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();return proxy.creatVocherOeder(voucherId);}}/*** 实现一人一单* @param voucherId* @return*/@Transactionalpublic  Result creatVocherOeder(Long voucherId){//5.一人一单Long userId = UserHolder.getUser().getId();//5.1查询订单int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();//判断是否存在if( count > 0){//用户已经购买过了return Result.fail("用户已购买一次!");}//6.扣减库存boolean success =  seckillVoucherService.update().setSql("stock = stock -1 ")//set stock = stock -1.eq("voucher_id",voucherId).gt("stock",0)// where id = ? and stock > 0.update();if(!success){//扣减失败return Result.fail("库存不足！");}//6.创建订单VoucherOrder voucherOrder = new VoucherOrder();//6.1订单idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);//6.2用户idvoucherOrder.setUserId(userId);//6.3代金劵idvoucherOrder.setVoucherId(voucherId);save(voucherOrder);//返回订单return Result.ok(orderId);}}

思考：整体代码的耦合度是不是太高了，sql语句写在xml里是不是更好去维护更新？

虽然这个项目主体表现的redis，但是既然学了springcloud的知识，在微服务项目中，我们去处理这个问题时，是不是就牵扯到服务之间的访问，又会牵扯到服务之间的唯一访问，所有这里锁的设计对我收获很大。