基于Redis的网上点评项目

目录

一、短信验证登录

1.基于session实现

2.基于session实现登陆的问题

3.基于redis实现短信登陆

二、Redis缓存

1.选择缓存更新策略

1.业务逻辑

3.缓存存在的问题

3.1 缓存穿透

3.2 缓存雪崩

3.3 缓存击穿

三、优惠券秒杀

1.秒杀下单功能

2.超卖问题

3.一人一单功能

4.一人一单的并发安全问题

5.基于Redis的分布式锁

1、实现分布式锁需要实现的两个方法：

2、实现思路

3、代码实现

4、测试

5、Redis分布式锁的误删问题

6、Redis分布式锁的原子性问题

7、秒杀优化

四、达人探店

1、发布探店笔记

2、点赞功能

3、点赞排行榜

五、好友关注

1、关注和取关

2、共同关注

3、关注推送

六、附近商户

1、GEO数据结构

2、搜索附近商户

七、用户签到

1、签到功能

2、签到统计

---

项目学习来源：

黑马程序员Redis入门到实战教程，深度透析redis底层原理+redis分布式锁+企业解决方案+黑马点评实战项目_哔哩哔哩_bilibili

 

一、短信验证登录

1.基于session实现

2.基于session实现登陆的问题

单体应用时用户的会话信息保存在session中，session存在于服务器端的内存中，由于前前后后用户只针对一个web服务器，所以没啥问题。但是一到了web服务器集群的环境下（我们一般都是用Nginx做负载均衡，若是使用了轮询等这种请求分配策略），就会导致用户在A服务器登录了，session存在于A服务器中，但是第二次请求被分配到了B服务器，由于B服务器中没有该用户的session会话，导致该用户还要再登陆一次，以此类推。这样用户体验很不好。当然解决办法也有很多种，比如同一个用户分配到同一个服务处理、使用cookie保持用户会话信息等。

因此，要解决这样的问题必须满足以下条件：

• 数据共享
• 内存存储
• key、value结构

因此，我们可以利用Redis来实现登录的功能。

3.基于redis实现短信登陆

1、发送验证码功能：

/**
 * 发送手机验证码
 */
@PostMapping("code")
public Result sendCode(@RequestParam("phone") String phone, HttpSession session) {
    return userService.sendCode(phone,session);
}

@Override
public Result sendCode(String phone, HttpSession session) {
        //判断手机号格式是否有效
        if (RegexUtils.isPhoneInvalid(phone)) {
            //无效则返回失败信息
            return Result.fail("手机号格式有误!");
        }
        //手机号有效，则生成6位验证码
        String code = RandomUtil.randomNumbers(6);
        //将验证码保存在Redis中,有效时间2分钟
        stringRedisTemplate.opsForValue().set(LOGIN_CODE_KEY+phone,code,LOGIN_CODE_TTL, TimeUnit.MINUTES);
        //将手机号保存在Redis中，有效时间2分钟
        stringRedisTemplate.opsForValue().set(LOGIN_PHONE_KEY+phone,phone,LOGIN_PHONE_TTL,TimeUnit.MINUTES);
        //控制台显示验证码
        log.info("验证码发送成功，验证码为:{}",code);
        return Result.ok();
    }

2、登录功能：

该 login方法会把生成的token返回给前端，前端会将token保存在请求头中，并且添加前端拦截器，每次发送请求时拦截器会将token保存到请求头中，这样后端就能够接收到token并进行验证。

    /**
     * 登录功能
     * @param loginForm 登录参数，包含手机号、验证码；或者手机号、密码
     */
    @PostMapping("/login")
    public Result login(@RequestBody LoginFormDTO loginForm, HttpSession session){
        //实现登录功能
        return userService.login(loginForm,session);
    }

	/**
     * 登录功能
     * @param loginForm
     * @param session
     * @return
     */
	@Override
    public Result login(LoginFormDTO loginForm, HttpSession session) {
    //判断手机号是否为当前发送验证码的手机号
    String redisPhone = stringRedisTemplate.opsForValue().get(LOGIN_PHONE_KEY + loginForm.getPhone());
    if (loginForm.getPhone() == null || !(redisPhone.equals(loginForm.getPhone()))) {
        return Result.fail("手机号有误");
    }
    //判断验证码是否有效
    if (RegexUtils.isCodeInvalid(loginForm.getCode())) {
        return Result.fail("验证码格式有误");
    }
    //判断验证码是否一致
    String redisCode = stringRedisTemplate.opsForValue().get(LOGIN_CODE_KEY + redisPhone);
    if (redisCode==null || !(redisCode.equals(loginForm.getCode()))){
        return Result.fail("验证码不正确");
    }
    //判断用户是否在数据库中已存在
    User user = getOne(new LambdaQueryWrapper().eq(User::getPhone, loginForm.getPhone()));
    if(user == null){
        //不存在,则创建用户
        user = createUserWithPhone(loginForm.getPhone());
    }
    //已存在，则将用户信息保存在Redis中
    //属性拷贝：将数据封装到UserDTO中，用于隐藏用户的隐私信息
    UserDTO userDTO = BeanUtil.copyProperties(user, UserDTO.class);
    //随机生成token，作为登录令牌
    String token = UUID.randomUUID().toString(true);
    //将userDTO转为Map类型，并保存在Hash结构中(key,Map)
    //这里因为stringRedisTemple的key,value都为String类型，所以在存储时，保证Map集合的filed,value也为String类型
    HashMap userMap = new HashMap<>();
    userMap.put("id",userDTO.getId().toString());
    userMap.put("nickName",userDTO.getNickName());
    userMap.put("icon",userDTO.getIcon());
    //用户信息作为value，token作为key保存在Redis中
    String key = LOGIN_USER_KEY+token;
    stringRedisTemplate.opsForHash().putAll(key,userMap);
    //设置token的有效时间30分钟
    stringRedisTemplate.expire(key,LOGIN_USER_TTL,TimeUnit.MINUTES);
    //将token返回给前端，前端会将token保存在请求头中，每次请求都会携带toekn，后端接收到token进行判断
    return Result.ok(token);
}

	/**
     * 创建用户
     * @param phone
     * @return
     */
    private User createUserWithPhone(String phone) {
        User user = new User();
        user.setPhone(phone);
        user.setNickName("user_"+RandomUtil.randomString(8));
        save(user);
        return user;
    }

*这里使用redis的hash结构存储user信息，原因是：

• 若使用String结构，以JSON字符串来保存，比较直观
• Hash结构可以将对象中的每个字段独立存储，可以针对单个字段做CRUD，并且内存占用更少

3、自定义拦截器：

首先，自定义两个拦截器：刷新token拦截器、登录拦截器。

对于每个请求，我们首先会根据获取到的token判断用户是否存在，并将获取到的用户保存到ThreadLocal中，刷新token有效期，然后登录拦截器会判断ThreadLocal中的用户是否存在，不存在则拦截，否则放行。

之后来到登陆拦截器，如果ThreadLocal没有用户，说明没有登陆则进行拦截，否则放行。

1. ThreadLocal工具类（UserHolder）：用于保存并设置当前登录用户信息。

/**
 * ThreadLocal类：用于保存和设置当前登录用户的信息
 */
public class UserHolder {
    private static final ThreadLocal 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();
    }
}

1. 刷新token拦截器

/**
 * 刷新token的拦截器
 * 1、该拦截器是自定义的，所以没有被Spring容器管理
 * 2、自定义的拦截器不能通过Spring容器进行依赖注入，因此这里利用构造函数实现依赖注入
 *    因为拦截器配置类是由Spring容器管理的，可以依赖注入redisTemple，然后将注入的对象传入到拦截器的构造函数中，就实现了依赖注入
 */
public class RefreshInterceptor implements HandlerInterceptor {

    private StringRedisTemplate stringRedisTemplate;

    public RefreshInterceptor(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    /**
     * 刷新token有效时间
     * @param request
     * @param response
     * @param handler
     * @return
     * @throws Exception
     */
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        //获取前端请求头中的token
        String token = request.getHeader("authorization");
        if (token==null){
            return true;
        }
        //根据token获取Redis中保存的用户信息
        String key = LOGIN_USER_KEY+token;
        Map userMap = stringRedisTemplate.opsForHash().entries(key);
        //判断用户是否存在
        if (userMap.isEmpty()) {
            return true;
        }
        //存在，则将当前登录用户保存在ThreadLocal中
            //将Map类型转换为UserDTO类型
        UserDTO userDTO = BeanUtil.fillBeanWithMap(userMap, new UserDTO(), false);
        UserHolder.saveUser(userDTO);
        //刷新token的有效时间
        stringRedisTemplate.expire(key,LOGIN_USER_TTL, TimeUnit.MINUTES);
        return true;
    }

    /**
     * 执行完后，清除当前用户信息，避免内存泄露
     * @param request
     * @param response
     * @param handler
     * @param ex
     * @throws Exception
     */
    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        //ThreadLocal底层是Map存储，以当前线程作为key,用户信息作为value，所以根据当前线程删除value
        UserHolder.removeUser();
    }
}

1. 登录拦截器

/**
 * 登录功能拦截器
 */
public class LoginInterceptor implements HandlerInterceptor {

    /**
     * 登录拦截器：判断用户是否已登录
     * @param request
     * @param response
     * @param handler
     * @return
     * @throws Exception
     */
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        //获取ThreadLocal中的用户信息
        UserDTO userDTO = UserHolder.getUser();
        //判断当前用户是否为空
        if (userDTO == null){
            //拦截
            response.setStatus(401);
            return false;
        }
        //放行
        return true;
    }
}

1. 拦截器配置类

/**
 * WebMvc配置类
 * 1、设置两个拦截器的原因：因为如果用户访问一个不需要拦截的首页面，30分钟后导致token会失效，
 *    所以配置两个拦截器，一个用于刷新token有效时间的拦截器，该拦截器会拦截所有请求，使得任何请求都会刷新token,该拦截器优先执行
 *                    一个用于拦截当前用户是否登录的拦截器，该拦截器拦截部分请求，该拦截器作为第二拦截器执行
 */
@Configuration
public class AdminMvcConfig implements WebMvcConfigurer {

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        //刷新token的拦截器，优先级高
        registry.addInterceptor(new RefreshInterceptor(stringRedisTemplate))
                .addPathPatterns("/**").order(0);
        //登录功能拦截器，优先级低
        registry.addInterceptor(new LoginInterceptor())
                .excludePathPatterns("/user/code",
                                     "/user/login",
                                     "/blog/hot",
                                     "shop-type/**",
                                     "/shop/**",
                                     "/upload/**",
                                     "/voucher/**"
                ).order(1);
    }
}

1. ThreadLocal补充：

• Thread类有一个类型为ThreadLocal，ThreadLocalMap的实例变量threadLocals，也就是说每个线程有一个自己的ThreadLocalMap。
• ThreadLocalMap有自己的独立实现，可以简单地将它的key视作ThreadLocal，value为代码中放入的值（实际上key并不是ThreadLocal本身，而是它的一个弱引用）。
• 每个线程在往ThreadLocal里放值的时候，都会往自己的ThreadLocalMap里存，读也是以ThreadLocal作为引用，在自己的map里找对应的key，从而实现了线程隔离。
• ThreadLocalMap有点类似HashMap的结构，只是HashMap是由数组+链表实现的，而ThreadLocalMap中并没有链表结构。
• 我们还要注意Entry， 它的key是ThreadLocal k ，继承自WeakReference， 也就是我们常说的弱引用类型。

内存泄漏问题： 由于ThreadLocal的key是代表当前线程，即弱引用，所以在gc时，key会被回收掉，但是value是强引用没有被回收，所以在我们拦截器的方法里必须手动remove()，即根据当前线程删除value。

二、Redis缓存

1.选择缓存更新策略

本项目选择了主动更新策略，相对较好，主动更新又有以下三种方式：

选择在更新数据库的同时更新缓存。操作缓存和数据库时有三个问题需要考虑：

• 删除缓存还是更新缓存？

• • 更新缓存：每次更新数据库都更新缓存，无效写操作较多
  • 删除缓存：更新数据库时让缓存失效，查询时再更新缓存

• 如何保证缓存与数据库的操作的同时成功或失败？

• • 单体系统，将缓存与数据库操作放在一个事务
  • 分布式系统，利用TCC等分布式事务方案

• 先操作缓存还是先操作数据库？

• • 先操作数据库

1.业务逻辑

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

    /**
     * 根据ID查询商铺信息--基于Redis查询
     * @param id
     * @return
     */
    @Override
    public Result queryShopById(Long id) {
        //根据ID查询Redis中是否存在
        String key = CACHE_SHOP_KEY+id;
        String shopJSON = stringRedisTemplate.opsForValue().get(key);
        //Redis有，则直接返回
        if (StringUtils.isNotBlank(shopJSON)){
            //将json数据转为java对象
            Shop shop = JSONUtil.toBean(shopJSON, Shop.class);
            return Result.ok(shop);
        }
        //没有，则查询数据库
        Shop shop = getById(id);
        if (shop == null){
            //数据库中没有，则返回fail
            return Result.fail("该商铺不存在");
        }
        //数据库有，则将查询到的数据保存到Redis中
        stringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(shop),CACHE_SHOP_TTL, TimeUnit.MINUTES);
        //返回给前端
        return Result.ok(shop);
    }

	/**
     * 根据ID修改商铺信息，并清空缓存
     * @param shop
     * @return
     */
    @Override
    public Result update(Shop shop) {
        //判断商铺是否存在
        if (shop.getId()==null){
            return Result.fail("该商铺不存在");
        }
        //根据ID修改商铺信息
        updateById(shop);
        //清空缓存
        stringRedisTemplate.delete(CACHE_SHOP_KEY+shop.getId());
        return Result.ok("商铺更新成功");
    }

/**
     * 查询商铺类型列表--基于Redis查询
     * @return
     */
    @Override
    public Result queryShopTypeList() {
        //查询Redis中是否存在
        String shoptypeJSON = stringRedisTemplate.opsForValue().get(CACHE_SHOPTYPE_KEY);
        if (StringUtils.isNotBlank(shoptypeJSON)){
            //存在，则直接返回
            List shopTypes = JSONUtil.toList(shoptypeJSON, ShopType.class);
            return Result.ok(shopTypes);
        }
        //不存在，则查询数据库中是否存在
        List list = query().orderByAsc("sort").list();
        if (list == null){
            //不存在，则返回空
            return Result.fail("商铺分类不存在");
        }
        //存在，则将数据保存到Redis中
        String jsonStr = JSONUtil.toJsonStr(list);
        stringRedisTemplate.opsForValue().set(CACHE_SHOPTYPE_KEY,jsonStr,CACHE_SHOPTYPE_TTL, TimeUnit.MINUTES);
        //返回给前端
        return Result.ok(list);
    }

3.缓存存在的问题

3.1 缓存穿透

问题：缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库。
常见的解决方案有两种：

• 缓存空对象
  优点：实现简单，维护方便
  缺点：额外的内存消耗，可能造成短期的不一致
  适合命中不高，但可能被频繁更新的数据
• 布隆过滤
  优点：内存占用较少，没有多余key
  缺点：实现复杂，存在误判可能
  适合命中不高，但是更新不频繁的数据

解决方案：

    /**
     * 解决缓存穿透问题：缓存空值
     * @param id
     * @return
     */
    public Shop queryWithPassThrough(Long id){
        //根据ID查询Redis中是否存在
        String key = CACHE_SHOP_KEY+id;
        String shopJSON = stringRedisTemplate.opsForValue().get(key);
        //Redis有，则直接返回
        //isNotBlank：不为null、不为""、length!=0
        if (StringUtils.isNotBlank(shopJSON)){
            //将json数据转为java对象
            return JSONUtil.toBean(shopJSON, Shop.class);
        }
        //判断查询到的是否为空值""
        if ("".equals(shopJSON)){
            return null;
        }
        //不存在，则查询数据库
        Shop shop = getById(id);
        if (shop == null){
            //数据库中没有，则缓存空值到Redis中
            stringRedisTemplate.opsForValue().set(key,"",CACHE_NULL_TTL,TimeUnit.MINUTES);
            return null;
        }
        //数据库有，则将查询到的数据保存到Redis中
        stringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(shop),CACHE_SHOP_TTL, TimeUnit.MINUTES);
        //返回给前端
        return shop;
    }

3.2 缓存雪崩

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

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

3.3 缓存击穿

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

• 互斥锁
• 逻辑过期

两种方案对比：

3.3.1 互斥锁解决缓存击穿问题

    /**
     * 利用互斥锁解决缓存击穿问题
     * @param id
     * @return
     */
    public Shop queryWithMutex(Long id){
        //根据ID查询Redis中是否存在
        String key = CACHE_SHOP_KEY+id;
        String shopJSON = stringRedisTemplate.opsForValue().get(key);
        //Redis有，则直接返回
        //isNotBlank：不为null、不为""、length!=0
        if (StringUtils.isNotBlank(shopJSON)){
            //将json数据转为java对象
            return JSONUtil.toBean(shopJSON, Shop.class);
        }
        //判断查询到的是否为空值""
        if ("".equals(shopJSON)){
            return null;
        }

        //不存在，则查询数据库实现缓存重建
        String lockKey = LOCK_SHOP_KEY+id;
        Shop shop = null;
        try {
            //1、获取互斥锁
            boolean isLock = tryLock(lockKey);
            //2、判断是否获取到锁
            if (!isLock){
            //3、失败，则休眠一段时间并重试  这里用到了递归，return结束递归
              Thread.sleep(50);
              return queryWithMutex(id);
            }
            //4、成功，则查询数据库，将数据写入缓存
            shop = getById(id);
            //模拟重建的延时
            Thread.sleep(200);
            if (shop == null){
                //数据库中没有，则缓存空值到Redis中
                stringRedisTemplate.opsForValue().set(key,"",CACHE_NULL_TTL,TimeUnit.MINUTES);
                return null;
            }
            //数据库有，则将查询到的数据保存到Redis中
            stringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(shop),CACHE_SHOP_TTL, TimeUnit.MINUTES);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }finally {
            //释放锁
            unLock(lockKey);
        }
        //返回给前端
        return shop;
    }

    /**
     * 获取互斥锁：利用Redis中的setnx方法实现互斥锁的功能，当且仅当key不存在时设置其value值
     * @param key
     * @return
     */
    public boolean tryLock(String key){
        //设置互斥锁
        Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(key, "lock", LOCK_SHOP_TTL, TimeUnit.SECONDS);
        return BooleanUtil.isTrue(flag);
    }

    /**
     * 释放互斥锁
     * @param key
     */
    public void unLock(String key){
        stringRedisTemplate.delete(key);
    }

3.3.2 设置逻辑过期解决缓存击穿问题

[点击并拖拽以移动]

	//创建线程池
    private static final ExecutorService CACHE_REBUILD_EXECUTOR = Executors.newFixedThreadPool(10);

    /**
     * 设置逻辑过期时间解决缓存击穿问题
     * @param id
     * @return
     */
    public Shop queryWithLogicalExpire(Long id){
        //从Redis中查询商铺信息
        String shopJSON = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id);
        //判断是否存在
        if (StrUtil.isBlank(shopJSON)){
            //不存在
            return null;
        }

        //存在，则需要先将json反序列化为java对象
        RedisData redisData = JSONUtil.toBean(shopJSON, RedisData.class);
        Shop shop = JSONUtil.toBean((JSONObject) redisData.getData(), Shop.class);
        //判断缓存是否过期
        LocalDateTime expireTime = redisData.getExpireTime();
        if (expireTime.isAfter(LocalDateTime.now())){
            //未过期，则直接返回信息
            return shop;
        }
        //已过期，则重建缓存
            //获取互斥锁
        String lockKey = CACHE_SHOP_KEY + id;
        boolean isLock = tryLock(lockKey);
            //判断是否获取成功
        if (isLock){
            //成功，则开启独立线程，进行缓存重建
            CACHE_REBUILD_EXECUTOR.submit(() -> {
                    //重建缓存
                    saveShop2Redis(id,20L);
                    //释放锁
                    unLock(lockKey);
            });
        }
            //失败，则返回过期的店铺信息
        return shop;
    }

    /**
     * 重建缓存：将数据库查询到的数据写入缓存
     * @param id
     */
    public void saveShop2Redis(Long id,Long expireTime){
        //查询店铺信息
        Shop shop = getById(id);
        //封装查询到的数据和逻辑过期时间
        RedisData redisData = new RedisData();
        redisData.setData(shop);
        redisData.setExpireTime(LocalDateTime.now().plusSeconds(expireTime));
        //写入Redis
        stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY+id,JSONUtil.toJsonStr(redisData));
    }

​

三、优惠券秒杀

1.秒杀下单功能

    /**
     * 优惠券秒杀的下单功能
     * @param voucherId
     * @return
     */
    @Override
    public Result seckillVoucher(Long voucherId) {
        //查询优惠券
        SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
        //判断优惠券秒杀是否开始
        if (voucher.getBeginTime().isAfter(LocalDateTime.now())){
            //尚未开始
            return Result.fail("秒杀尚未开始");
        }
        //判断优惠券秒杀是否已经结束
        if (voucher.getEndTime().isBefore(LocalDateTime.now())){
            //已经结束
            return Result.fail("秒杀已经结束");
        }
        //判断库存是否充足
        if (voucher.getStock() < 1){
            //库存不足
            return Result.fail("库存不足");
        }
        //扣减库存
        boolean success = seckillVoucherService.update()
                .setSql("stock = stock -1")
                .eq("voucher_id", voucherId).update();
        //判断扣减是否成功
        if (!success){
            return Result.fail("库存不足");
        }
        //创建订单
        VoucherOrder voucherOrder = new VoucherOrder();
          //订单id
        long orderId = redisIDWorker.nextId("order");
        voucherOrder.setId(orderId);
          //用户id
        Long userId = UserHolder.getUser().getId();
        voucherOrder.setUserId(userId);
          //优惠券id
        voucherOrder.setVoucherId(voucherId);
        //新增订单
        save(voucherOrder);
        //返回订单ID
        return Result.ok(orderId);
    }

2.超卖问题

请求A查询库存，发现库存为1，请求B这时也来查询库存，库存也为1，然后请求A让数据库减1，这时候B查询到的仍然是1，也继续让库存减1，就会导致超卖。

1、解决方案：

乐观锁：认为线程安全问题不一定会发生，因此不加锁，只是在更新数据时去判断有没有其它线程对数据做了修改。

如果没有修改则认为是安全的，自己才更新数据。如果已经被其它线程修改说明发生了安全问题，此时可以重试或异常。

悲观锁：认为线程安全问题一定会发生，因此在操作数据之前先获取锁，确保线程串行执行。例如Synchronized、Lock都属于悲观锁。

2、实现乐观锁主要有以下两种方法：

1. 版本号法：

每次更新数据库的时候按照版本查询，并且要更新版本。

1. CAS

CAS是英文单词Compare And Swap的缩写，翻译过来就是比较并替换。该方法是版本号法的简化

CAS的缺点：

• CPU开销较大：在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。

• 不能保证代码块的原子性：CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。

3、业务逻辑

//判断库存是否充足
        if (voucher.getStock() < 1){
            //库存不足
            return Result.fail("库存不足");
        }
        //扣减库存 update tb_seckill_voucher set stock=stock-1 where voucher_id=? and stock>0
        boolean success = seckillVoucherService.update()
                .setSql("stock = stock -1")
                .eq("voucher_id", voucherId)
                .gt("stock",0)
                .update();
        //判断扣减是否成功
        if (!success){
            return Result.fail("库存不足");
        }

3.一人一单功能

要求同一个优惠券，一个用户只能下单一次

这样的方式会产生线程安全问题，问题和超卖情况类似，所以这里需要用到悲观锁，逻辑如下：

    /**
     * 优惠券秒杀的下单功能
     * @param voucherId
     * @return
     */
    @Override
    public Result seckillVoucher(Long voucherId) {
        //查询优惠券
        SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
        //判断优惠券秒杀是否开始
        if (voucher.getBeginTime().isAfter(LocalDateTime.now())){
            //尚未开始
            return Result.fail("秒杀尚未开始");
        }
        //判断优惠券秒杀是否已经结束
        if (voucher.getEndTime().isBefore(LocalDateTime.now())){
            //已经结束
            return Result.fail("秒杀已经结束");
        }
        //判断库存是否充足
        if (voucher.getStock() < 1){
            //库存不足
            return Result.fail("库存不足");
        }

        //保证事务提交之后再释放锁
        //同步监视器：userId，保证一个用户用的是同一把锁
        //创建代理对象，实现事务管理功能，避免使用被代理类而导致事务失效，
        //    并且需要在启动类加注解@EnableAspectJAutoProxy(exposeProxy = true)，暴露该代理对象才能获取
        Long userId = UserHolder.getUser().getId();
        synchronized(userId.toString().intern()){
            //获取代理对象（事务）
            IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
            return proxy.createVoucherOrder(voucherId);
        }
    }

    /**
     * 优惠券订单生成
     * @param voucherId
     * @return
     */
    @Transactional
    public Result createVoucherOrder(Long voucherId) {
        //实现一人一单
        Long userId = UserHolder.getUser().getId();
        //查询优惠券订单
        int count = query().eq("voucher_id", voucherId).eq("user_id", userId).count();
        //判断订单是否存在
        if (count>0){
            //该用户已经购买过了
            return Result.fail("用户已经购买一次!");
        }

        //扣减库存 update tb_seckill_voucher set stock=stock-1 where voucher_id=? and stock>0
        boolean success = seckillVoucherService.update()
                .setSql("stock = stock -1")
                .eq("voucher_id", voucherId)
                .gt("stock",0)
                .update();
        //判断扣减是否成功
        if (!success){
            return Result.fail("库存不足");
        }
        //创建订单
        VoucherOrder voucherOrder = new VoucherOrder();
        //订单id
        long orderId = redisIDWorker.nextId("order");
        voucherOrder.setId(orderId);
        //用户id
        voucherOrder.setUserId(userId);
        //优惠券id
        voucherOrder.setVoucherId(voucherId);
        //新增订单
        save(voucherOrder);
        //返回订单ID
        return Result.ok(orderId);
    }

4.一人一单的并发安全问题

通过加锁的方式可以解决在单机情况下的一人一单安全问题，但是在集群模式下就不行了（每个jvm都有自己的锁监视器，集群模式下各个服务器的锁不共享）。
因此，我们的解决方案就是实现一个共享的锁监视器，即：
分布式锁：满足分布式系统或集群模式下多进程可见并且互斥的锁。 分布式锁满足：多进程可见、互斥、高可用、高性能、安全性等。

因此，下面通过基于Redis的分布式锁来解决一人一单的并发安全问题。

5.基于Redis的分布式锁

1、实现分布式锁需要实现的两个方法：

1. 获取锁

• 互斥：确保只能有一个线程获取锁
• 非阻塞：尝试一次，成功返回true，失败返回false

1. 释放锁

• 手动释放
• 超时释放：获取锁时设置一个超时时间

2、实现思路

3、代码实现

/**
 * 基于Redis实现分布式锁
 */
public class SimpleRedisLock implements ILock{

    //业务名称,即不同业务有不同的锁key
    private String name;
    private StringRedisTemplate stringRedisTemplate;

    public SimpleRedisLock(String name, StringRedisTemplate stringRedisTemplate) {
        this.name = name;
        this.stringRedisTemplate = stringRedisTemplate;
    }

    //互斥锁key前缀
    private static final String KEY_PREFIX = "lock:";

    /**
     * 尝试获取锁
     * @param timeoutSec 锁的过期时间，过期后自动释放
     * @return
     */
    @Override
    public boolean tryLock(long timeoutSec) {
        //获取当前线程的ID
        long threadId = Thread.currentThread().getId();
        Boolean success = stringRedisTemplate.opsForValue().setIfAbsent(KEY_PREFIX + name, threadId+"", timeoutSec, TimeUnit.SECONDS);
        return Boolean.TRUE.equals(success);
    }

    /**
     * 释放锁
     */
    @Override
    public void unLock() {
        stringRedisTemplate.delete(KEY_PREFIX+name);
    }
}

/**
     * 优惠券秒杀的下单功能
     * @param voucherId
     * @return
     */
    @Override
    public Result seckillVoucher(Long voucherId) {
        //查询优惠券
        SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
        //判断优惠券秒杀是否开始
        if (voucher.getBeginTime().isAfter(LocalDateTime.now())){
            //尚未开始
            return Result.fail("秒杀尚未开始");
        }
        //判断优惠券秒杀是否已经结束
        if (voucher.getEndTime().isBefore(LocalDateTime.now())){
            //已经结束
            return Result.fail("秒杀已经结束");
        }
        //判断库存是否充足
        if (voucher.getStock() < 1){
            //库存不足
            return Result.fail("库存不足");
        }

        //这里锁key的设计，是针对当前业务的同一个用户进行互斥锁，来保证同一个用户只能下一单。并且减小锁的范围，不同用户不会受到互斥的限制
        Long userId = UserHolder.getUser().getId();
        //创建锁对象
        SimpleRedisLock redisLock = new SimpleRedisLock("order"+userId.toString(),stringRedisTemplate);
        //尝试获取锁
        boolean isLock = redisLock.tryLock(1);
        //判断是否获取到
        if (!isLock){
            //获取锁失败，返回错误
            return Result.fail("不允许重复下单");
        }
        try {
            //获取代理对象（事务）    保证事务提交之后再释放锁
            IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
            return proxy.createVoucherOrder(voucherId);
        } finally {
            //释放锁
            redisLock.unLock();
        }
    }

4、测试

通过模拟集群模式并进行测试，发现能够解决在集群模式下一人一单带来的并发安全问题，保证了多进程之间的可见并且互斥。

可以看到，数据库优惠券库存数减1，订单量加1：

因此，通过Redis的setnx命令能够实现互斥，进而能够实现分布式锁，因为不同服务之间共享同一个Redis服务器，而Redis服务器中的锁key是唯一的，实现了不同服务共享同一个锁监视器。

5、Redis分布式锁的误删问题

1、误删问题

当前我们基于Redis实现的分布式锁还存在一个锁误删的问题，简单来说，当线程1获取到锁后发生了业务阻塞导致锁超时释放了，这时线程2获取到了锁并执行业务，恰好此时线程1业务执行完成了并释放锁，导致线程2的锁被误删释放，就造成了锁误删问题。因此，要针对误删问题改进分布式锁。

2、解决误删问题的实现思路：

1. 在获取锁时存入线程标示（可以用UUID表示），这里考虑使用UUID是因为多个服务之间的线程ID可能相同，采用的都是ID递增策略。所以用UUID+线程ID来保证多个服务之间的线程ID唯一且各不相同。
2. 在释放锁时先获取锁中的线程标示，判断是否与当前线程标示一致

• 如果一致则释放锁
• 如果不一致则不释放锁

3、代码实现

/**
 * 基于Redis实现分布式锁
 */
public class SimpleRedisLock implements ILock{

    //业务名称,即不同业务有不同的锁key
    private String name;
    private StringRedisTemplate stringRedisTemplate;

    public SimpleRedisLock(String name, StringRedisTemplate stringRedisTemplate) {
        this.name = name;
        this.stringRedisTemplate = stringRedisTemplate;
    }

    //互斥锁key前缀
    private static final String KEY_PREFIX = "lock:";
    //线程标示的UUID
    private static final String ID_PREFIX = UUID.randomUUID().toString(true)+"-";

    /**
     * 尝试获取锁
     * @param timeoutSec 锁的过期时间，过期后自动释放
     * @return
     */
    @Override
    public boolean tryLock(long timeoutSec) {
        //生成当前线程的标示：UUID+线程ID
        String threadId = ID_PREFIX+Thread.currentThread().getId();
        //锁的value为线程的标示
        Boolean success = stringRedisTemplate.opsForValue().setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);
        return Boolean.TRUE.equals(success);
    }

    /**
     * 释放锁
     */
    @Override
    public void unLock() {
        //获取当前线程标示
        String threadId = ID_PREFIX+Thread.currentThread().getId();
        //获取锁的线程标示
        String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name);
        //判断线程标示是否一致
        if (threadId.equals(id)) {
            //一致，则释放锁
            stringRedisTemplate.delete(KEY_PREFIX + name);
        }
    }
}

6、Redis分布式锁的原子性问题

1、原子性问题：

当前我们基于Redis实现的分布式锁还存在原子性问题，简单来说，当线程1执行完业务进行释放锁时，会先判断当前锁的标示是否是自己的，条件成立后此时，线程1可能因为GC发生了阻塞，导致锁超时释放了，那么线程2获取到锁后执行业务，这个时候线程1由阻塞恢复为运行状态，接着就会释放锁(因为线程1之前已经进行过释放锁的判断了)，导致线程2的锁被释放，因此出现了释放锁的原子性问题。

2、解决方案：

通过Lua脚本解决多条命令的原子性问题。Redis提供了Lua脚本功能，在一个脚本中编写多条Redis命令，确保多条命令执行时的原子性。

Lua是一种编程语言，它的基本语法大家可以参考网站：Lua 教程 | 菜鸟教程

如果脚本中的key、value不想写死，可以作为参数传递。key类型参数会放入KEYS数组，其它参数会放入ARGV数组，在脚本中可以从KEYS和ARGV数组获取这些参数：

3、实现思路

首先基于Lua脚本编写分布式锁的释放锁逻辑，然后在Java中通过RedisTemplate提供的API来调用Lua脚本。

4、代码实现

--判断锁的标示和当前线程标示是否一致
if (redis.call('get', KEYS[1]) == ARGV[1]) then
    --释放锁 del key
    return redis.call('del',KEYS[1])
end
    return 0

/**
 * 基于Redis实现分布式锁
 */
public class SimpleRedisLock implements ILock{

    //业务名称,即不同业务有不同的锁key
    private String name;
    private StringRedisTemplate stringRedisTemplate;

    public SimpleRedisLock(String name, StringRedisTemplate stringRedisTemplate) {
        this.name = name;
        this.stringRedisTemplate = stringRedisTemplate;
    }

    //互斥锁key前缀
    private static final String KEY_PREFIX = "lock:";
    //线程标示的UUID
    private static final String ID_PREFIX = UUID.randomUUID().toString(true)+"-";
    //初始化脚本对象,用于加载Lua脚本  这里定义为static是为了在类加载时就初始化该脚本对象，并且只会初始化一次，提高IO性能
    private static final DefaultRedisScript redisScript;
    static {
        redisScript = new DefaultRedisScript<>();
        redisScript.setLocation(new ClassPathResource("unlock.lua"));
        redisScript.setResultType(Long.class);
    }

    /**
     * 尝试获取锁
     * @param timeoutSec 锁的过期时间，过期后自动释放
     * @return
     */
    @Override
    public boolean tryLock(long timeoutSec) {
        //生成当前线程的标示：UUID+线程ID
        String threadId = ID_PREFIX+Thread.currentThread().getId();
        //锁的value为线程的标示
        Boolean success = stringRedisTemplate.opsForValue().setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);
        return Boolean.TRUE.equals(success);
    }


    /**
     * 释放锁
     */
    @Override
    public void unLock() {
        //调用Lua脚本
        stringRedisTemplate.execute(redisScript, 
                Collections.singletonList(KEY_PREFIX + name),
                ID_PREFIX+Thread.currentThread().getId());
    }
}

7、秒杀优化

详情见：

2.3基于阻塞队列实现异步秒杀

2.4 Redis消息队列实现异步秒杀

四、达人探店

1、发布探店笔记

    /**
     * 发布探店笔记
     * @param blog
     * @return
     */
    @PostMapping
    public Result saveBlog(@RequestBody Blog blog) {
        // 获取登录用户
        UserDTO user = UserHolder.getUser();
        blog.setUserId(user.getId());
        // 保存探店博文
        blogService.save(blog);
        // 返回id
        return Result.ok(blog.getId());
    }

/**
     * 探店笔记图片上传功能
     * @param image
     * @return
     */
    @PostMapping("blog")
    public Result uploadImage(@RequestParam("file") MultipartFile image) {
        try {
            // 获取原始文件名称
            String originalFilename = image.getOriginalFilename();
            // 生成新文件名
            String fileName = createNewFileName(originalFilename);
            // 保存文件
            image.transferTo(new File(SystemConstants.IMAGE_UPLOAD_DIR, fileName));
            // 返回结果
            log.debug("文件上传成功，{}", fileName);
            return Result.ok(fileName);
        } catch (IOException e) {
            throw new RuntimeException("文件上传失败", e);
        }
    }

2、点赞功能

1、需求：

• 同一个用户只能点赞一次，再次点击则取消点赞
• 如果当前用户已经点赞，则点赞按钮高亮显示（前端已实现，判断字段Blog类的isLike属性）

2、实现步骤：

1. 给Blog类中添加一个isLike字段，标示是否被当前用户点赞过
2. 修改点赞功能，利用Redis的zset集合判断是否点赞过，未点赞过则点赞数+1，已点赞过则点赞数-1
3. 修改根据id查询Blog的业务，判断当前登录用户是否点赞过，赋值给isLike字段
4. 修改分页查询Blog业务，判断当前登录用户是否点赞过，赋值给isLike字段

3、代码实现

    /**
     * 点赞功能:使用sortedSet集合
     * @param id
     * @return
     */
    @Override
    public Result likeBlog(Long id) {
        //获取当前用户信息
        Long userId = UserHolder.getUser().getId();
        //判断当前用户是否已点赞过
        String key = BLOG_LIKED_KEY + id;
        Double score = stringRedisTemplate.opsForZSet().score(key, userId.toString());
        if (score==null){
            //未点赞，可以点赞
            //数据库点赞数+1
            boolean success = update().setSql("liked = liked + 1").eq("id", id).update();
            //Redis的zset集合添加该用户
            if (success){
                stringRedisTemplate.opsForZSet().add(key,userId.toString(),System.currentTimeMillis());
            }
        }else {
            //已点赞，取消点赞
            //数据库点赞数-1
            UpdateWrapper wrapper = new UpdateWrapper<>();
            wrapper.setSql("liked = liked - 1");
            wrapper.eq("id",id);
            boolean success = update(wrapper);
            //删除Redis的set集合中的该用户
            if (success){
                stringRedisTemplate.opsForZSet().remove(key,userId.toString());
            }
        }
        return Result.ok();
    }

3、点赞排行榜

1、需求

按照点赞时间的先后顺序，将给指定笔记点赞的前TOP5用户显示出来，形成排行榜。

2、实现思路

实现点赞排行榜的功能，需要使用sortedSet集合，利用score命令判断用户是否点过赞，并且利用时间戳作为权值对点赞时间先后的用户进行排序。

3、代码实现

    /**
     * 查看指定笔记的点赞排行榜
     * @param id
     * @return
     */
    @Override
    public Result queryBlogLikes(Long id) {
        String key = BLOG_LIKED_KEY + id;
        //查询top5的点赞用户 zrange key 0 4
        Set top5 = stringRedisTemplate.opsForZSet().range(key, 0, 4);
        if (top5 == null || top5.isEmpty()){
            return Result.ok(Collections.emptyList());
        }
		/*
        //根据用户ID查询用户信息 WHERE id IN(5,1) ORDER BY FIELD(id,5,1)
        String idStr = StrUtil.join(",", ids);
        List