猫十二懿

黑马Redis-实战篇（黑马点评）

✨作者：猫十二懿

❤️‍账号：CSDN 、掘金、个人博客、Github

公众号：猫十二懿

Redis - 实战篇

黑马点评项目地址

本次实战篇是通过一个畅享旅途的项目来扩展讲解Redis中的知识点，更好的理解，并且知道怎么在实际的开放中运用。

整体思维导图

短信验证码的登录注册功能

基于Session实现登录

实现发送短信验证码功能

@Override
    public Result sendCode(String phone, HttpSession session) {
    //1. 校验手机号（正则表达式）
    // RegexUtils.isPhoneInvalid(phone)是项目中已提前写好的，校验手机号格式的方法，内部也是用正则表达式，返回的布尔值是判断是否无效
    if (RegexUtils.isPhoneInvalid(phone)) {
        // 1.1 返回给前端 报错信息
        return Result.fail("手机号格式错误");
    }
    //2. 生成验证码
    String code = RandomUtil.randomNumbers(6);
    //3. 保存验证码到session
    session.setAttribute("code",code);
    //4. 发送验证码 (可能会用到第三方短信服务，这里的项目就不演示了)
    log.debug("短信验证码是： {}",code);
    return Result.ok();
}

实现短信验证码登录功能

    @Override
    public Result login(LoginFormDTO loginForm, HttpSession session) {
        // 这个验证是有问题的，因为他是将手机号和验证码分开验证的，并没有关联验证，
        // 如果手机号发生改变的话，也会登录成功，在下一个版本会用redis代替
        // 1. 从 loginForm里面拿到手机号，验证码进行校验
        String phone = loginForm.getPhone();
        Object code = session.getAttribute("code");
        if(code==null||!code.toString().equals(loginForm.getCode())){
            // 1.1 返回给前端 报错信息
            return Result.fail("验证码错误");
        }
        if (RegexUtils.isPhoneInvalid(phone)) {
            // 1.1 返回给前端 报错信息
            return Result.fail("手机号格式错误");
        }
        // 2.根据手机号查用户
        QueryWrapper<User> wrapper = new QueryWrapper<>();
        wrapper.eq("phone",phone);
        User one = this.getOne(wrapper);
        // 3.如果用户不存在，创建新用户
        if(one==null){
           one= createUserWithPhone(phone);
        }
        // 4.如果用户存在，保存用户脱敏信息到session
        session.setAttribute("user",one);
        return Result.ok();
    }

实现校验登录状态功能（登录拦截器）

idea 查看接口的方法的快捷键 Ctrl+I

不熟悉 ThreadLocal的小伙伴可以看这篇文章 https://zhuanlan.zhihu.com/p/102744180

public class LoginInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 1. 从session中获取用户信息
        Object user = request.getSession().getAttribute("user");
        // 2.判断用户是否存在
        if (user == null) {
            // user为空，则登录信息不存在，进行拦截
            // 这里不需要再对数据库进行查询了，因为如果这个登录信息不在数据库中，他就不会登录成功。
            response.setStatus(404);
            return false;
        }
        //3.保存用户的脱敏信息到ThreadLocal中
        UserDTO userDTO = new UserDTO();
        BeanUtils.copyProperties((User)user,userDTO);
        UserHolder.saveUser(userDTO);
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        // 操作完成后，将登录的用户信息移除调，避免用户泄露
        UserHolder.removeUser();
    }
}

public class MVCConfig  implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LoginInterceptor())
                //对于不需要登录也能访问的路径进行放行
                .excludePathPatterns(
                        "/user/code",
                        "/user/login",
                        "/shop/**",
                        "/voucher/**",
                        "/shop-type/**",
                        "/blog/hot",
                        "upload/**"
                );
    }
}

用户信息脱敏

在dto中创建UserDTO类，也就是返回给前端的数据，并不需要返回其他的属性，只需要关键的就可以，也就是信息脱敏。

@Data
public class UserDTO {
    private Long id;
    private String nickName;
    private String icon;
}

在实现login的实现类中，将user对象数据源修改为 UserDTO

//7.保存用户信息到session，
session.setAttribute("user",BeanUtil.copyProperties(user,UserDTO.class));

还有其他的使用User类的地方，都要改成UserDTO 过滤类

基于Session实现登录的问题

存在session共享问题：多台 Tomcat并不共享session，当请求切换到不同 tomcat服务时导致数据丢失的问题，

下面是刚才登录功能的架构图，如果用户在第一个tomcat上登录了，然后请求的服务发到了第二个服务，

第二个tomcat上的session上没有登录信息，会导致请求失败

那如果要实现session共享，要满足的条件如下

数据共享
内存存储：Redis读写效率高
key，value结构

那用redis就可以解决这个问题

基于Redis实现共享session登录

我们这里在Redis里存对象，用Hash结构，而不是用json来存储，因为Hash结构可以将对象中每个字段独立存储，可以对单个字段做CRUD，内存占用更少。

其实用JSON字符串保存也可以，比较直观，这里就用Hash结构来存储。

这里用随机token来作为key存储对象数据，也是为了防止有人利用phone来获取用户信息

首先在发送验证码当中设置相关的业务，也就是堆保存到的手机号进行加密，实现Session共享（sedCode实现类当中）

    @Override
    public Result sendCode(String phone, HttpSession session) {
        //1. 校验手机号（正则表达式）
        // RegexUtils.isPhoneInvalid(phone)是项目中已提前写好的，校验手机号格式的方法，内部也是用正则表达式，返回的布尔值是判断是否无效
        if (RegexUtils.isPhoneInvalid(phone)) {
            // 1.1 返回给前端 报错信息
            return Result.fail("手机号格式错误");
        }
        //2. 生成验证码
        String code = RandomUtil.randomNumbers(6);
        //3. 保存验证码到redis,  相当于 set key value ex 120
        // 为了防止其他业务也是用手机号作为key，我们这里要给他加一个业务名前缀
        stringRedisTemplate.opsForValue().set(LOGIN_CODE_KEY+phone,code,LOGIN_CODE_TTL, TimeUnit.MINUTES);
        //4. 发送验证码 (可能会用到第三方短信服务，这里的项目就不演示了)
        log.debug("短信验证码是： {}",code);
        return Result.ok();
    }

在LoginInterceptor 类中，因为这个类是自定义的，Spring是没有能力管控到的，所以说我们在给引入StringRedisTemplate的时候要使用构造方法的形式进行引入

private StringRedisTemplate stringRedisTemplate;

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

然后在 preHandle 中将之前从Session中获取数据的进行修改成从Redis中获取数据：

@Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 1.获取请求头中的token
        String token = request.getHeader("authorization");
        // 2.判断用户是否存在
        if (StrUtil.isBlank(token)) {
            // 不存在，拦截
            response.setStatus(401);
            return false;
        }
        // 3.获取token的redis中的用户
        String tokenKey = RedisConstants.LOGIN_USER_KEY + token;
        Map<Object, Object> userMap = stringRedisTemplate.opsForHash().entries(tokenKey);
        if (userMap.isEmpty()){
            response.setStatus(401);
            return false;
        }
        // 4.将查询到的Hash数据转换为UserDTO对象
        UserDTO userDTO = BeanUtil.fillBeanWithMap(userMap, new UserDTO(), false);
        // 5.存在 保存用户信息到ThreadLocal
        UserHolder.saveUser(userDTO);
        // 6.刷新token有效期
        stringRedisTemplate.expire(tokenKey,RedisConstants.LOGIN_USER_TTL, TimeUnit.MINUTES);
        // 7.放行
        return true;
    }

登录拦截器的优化

虽然用户信息在Redis中保存的时候设置过期时间了，但是这个时间是当用户信息保存到 redis 后，只要过了30分钟后，用户信息就删除了。但是我们希望的情况是当用户超过30分钟没有访问才删除。所以我们要对拦截器进行优化。做到用户一直在访问，token就不会过期。

在token拦截器中，统一进行拦截，然后在登录的时候就不用再去进行拦截。主要就是完成刷新时，还是携带着同一个token。

/**
 * @author Shier 
 */
public class RefreshTokenInterceptor implements HandlerInterceptor {

    private StringRedisTemplate stringRedisTemplate;

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

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 1.获取请求头中的token
        String 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数据转为UserDTO
        UserDTO userDTO = BeanUtil.fillBeanWithMap(userMap, new UserDTO(), false);
        // 6.存在，保存用户信息到 ThreadLocal
        UserHolder.saveUser(userDTO);
        // 7.刷新token有效期
        stringRedisTemplate.expire(key, LOGIN_USER_TTL, TimeUnit.MINUTES);
        // 8.放行
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        // 移除用户
        UserHolder.removeUser();
    }
}

进行修改LoginInterceptor 修改

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

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        // 操作完成后，将登录的用户信息移除调，避免用户泄露
        UserHolder.removeUser();
    }
}

商户查询缓存

缓存介绍

什么是缓存？

缓存就是数据交换的缓存区（Cache），是存储数据的临时地方，一般读写性能较高。

所以说一般买电脑就是看CPU的缓存，CPU的缓存越大，性能也就越好，能够临时存储的数据就越多。

缓存的作用

降低后端负载（减少查询数据库，减少数据库的压力）
提高读写效率，降低响应时间

引入缓存也会存在着一定的成本，不能乱用缓存。

缓存的成本

数据一致性成本（当数据库的数据发生变化时，redis中以前缓存的还是旧数据）
代码维护成本（为了解决一致性，缓存击穿，缓存雪崩等问题，会提高代码复杂度）
运维成本

缓存工作的模型

当客户端发送请求时，首先会去Redis中进行查询，如果在Redis中查询到则会命中，如果不命中则会去数据库进行查询，如果还不命中就会将数据写入到Redis缓存当中，当用户再次发送请求的时候就可以命中。
当Redis中的缓存越多，命中率也越高。

    public Result queryById(Long id) {
        //1. 从Redis中查询商铺缓存
        String shopJson = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id);
        //2.判断缓存是否命中
        if (StrUtil.isNotBlank(shopJson)) {
            //3.缓存命中直接返回
            Shop shop = JSONUtil.toBean(shopJson, Shop.class);
            return Result.ok(shop);
        }
        //4.缓存未命中，根据商铺id查询数据库
        Shop shop = this.getById(id);
        if(shop==null){
            //5. 数据库中查询失败，直接返回
            return Result.fail("店铺不存在");
        }
        //6. 数据库中查询成功，将数据缓存到Redis中
        stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id,JSONUtil.toJsonStr(shop));
        return Result.ok(shop);
    }

小作业：将商铺类型缓存到Redis中

在ShopTypeController中将原来的代码注释掉

@GetMapping("list")
public Result queryTypeList() {
    // List typeList = typeService
    //         .query().orderByAsc("sort").list();
    // return Result.ok(typeList);

    // 使用List结构进行缓存店铺类型
    return typeService.queryShopTypeList();
}

在接口中创建该方法：

/**
 * 主页的分类查询的缓存
 * @return
 */
Result queryShopTypeList();

最后的缓存实现在实现类里面：

	/**
     * 店铺类型缓存
     * 使用的是Redis 中的List数据结构进行缓存
     * @return
     */
    @Override
    public Result queryShopTypeList() {
        // 1.从 Redis 中查询商铺缓存
        List<String> shopTypeJsonList = stringRedisTemplate.opsForList().range(CACHE_SHOP_TYPE_KEY, 0, -1);

        // 2.判断 Redis 中是否有该缓存
        if (shopTypeJsonList != null && !shopTypeJsonList.isEmpty()) {
            // 2.1.若 Redis 中存在该缓存，则直接返回
            ArrayList<ShopType> shopTypes = new ArrayList<>();
            for (String str : shopTypeJsonList) {
                shopTypes.add(JSONUtil.toBean(str, ShopType.class));
            }
            return Result.ok(shopTypes);
        }
        // 2.2.Redis 中若不存在该数据，则从数据库中查询，返回的是列表集合
        List<ShopType> shopTypes = query().orderByAsc("sort").list();

        // 3.判断数据库中是否存在
        if (shopTypes == null || shopTypes.isEmpty()) {
            // 3.1.数据库中也不存在，则返回 false
            return Result.fail("分类不存在！");
        }

        // 3.2.数据库中存在，则将查询到的信息存入 Redis
        for (ShopType shopType : shopTypes) {
            stringRedisTemplate.opsForList().rightPushAll(CACHE_SHOP_TYPE_KEY, JSONUtil.toJsonStr(shopType));
        }

        // 3.3返回
        return Result.ok(shopTypes);
    }

缓存更新策略

如果我们直接修改数据库数据，由于存在缓存，用户还是在使用旧的数据，不能及时的更新，所以说得进行缓存的更新。

主要是三种方法：

	内存淘汰（默认）	超时剔除	主动更新
说明	不用自己维护，利用Redis的内存淘汰机制，当内存不足时自动淘汰部分数据，下次查询时更新缓存	给缓存数据添加TTL时间，到期后自动删除缓存，下次查询时更新缓存	自己编写业务逻辑，在修改数据库的同时，更新缓存
一致性	差	一般	好
维护成本	无	低	高

更具业务场景进行选择对应的更新缓存：

低一致性需求：使用内存淘汰机制，例如商铺类型的查询缓存
高一致性需求：主动更新，并以超时剔除为兜底方案，例如店铺详情查询的缓存

主动更新策略

Cache Aside Pattern：自己写代码，在更新数据库的同时更新缓存
Read/Write Through Pattern：将缓存和数据库整合为一个服务，有服务来维护一致性，调用者调用该服务，无需关心缓存一致性问题。维护难，市场上较少
Write Behind Caching Pattern：调用者只操作缓存，由其他线程异步的将缓存数据持久化到数据库，保证最终一致。

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

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

综上，这两种情况都会发生异常情况，但是先操作数据库，再删除缓存的可能性较低（因为缓存执行的时间很短）

总结：

低一致性需求：使用内存淘汰机制，例如商铺类型的查询缓存
高一致性需求：主动更新，并以超时剔除为兜底方案，例如店铺详情查询的缓存

因为在我们基本都是使用Cache Aside Pattern 这个更新策略，但是存在着缓存不一致，线程之间的不安全的问题。所以在读写缓存时

读操作
- 缓存命中则直接返回
- 缓存未命中则查询数据库，并写入缓存，设定超时时间
写操作
- 先写数据库，在删除缓存
- 要保证数据库与缓存操作的原子性。

综合到点评项目：

给查询商铺的缓存添加超时剔除和主动更新的策略

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

在之前写好的查询实现方法中添加一个缓存过期时间

// 6. 数据库商铺存在，存入Redis
stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(shopId), CACHE_SHOP_TTL, TimeUnit.MINUTES);

实现商铺缓存与数据库的读写一致

    public Result update(Shop shop) {
        //1.先更新数据库
        this.updateById(shop);
        Long id = shop.getId();
        if(id==null){
            return Result.fail("店铺id不能未空");
        }
        //2.删除缓存
        stringRedisTemplate.delete(CACHE_SHOP_KEY +id);
        return Result.ok();
    }

由于这个项目没有管理员端，所以这个更新测试可以用 postman 来测试或者也可以在接口文档中进行测试

缓存穿透

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

客户端发送请求，会先从redis缓存中查询是否命中，未命中就会继续到数据库中查询，如果数据库中也没有命名（也就是在数据库中也没有查询到），如果是不怀好意的人就会就会这样把你的数据库搞崩了，这就是缓存穿透。

为了解决缓存穿透，有以下两种方案

缓存空对象

也就是在首次请求中如果redis和数据库都没有命中，则数据库会将这个未命中的缓存(也就是null值)写入到redis缓存中，再次请求不命中时，就会从redis中返回null，就不用每次都访问到数据库
- 优点：实现简单，维护方便
- 缺点：
  - 额外的内存消耗
  - 可能造成数据短期的不一致（当在redis查询id1时，不存在，数据库也不存在，缓存null，就在这时，这条数据插入数据库了，那再查时还是null，当TTL（Time To Live）过期了才会得到最新的数据）
布隆过滤（布隆过滤器里面存的是 byte数组，将对象基于某种算法计算 hash值）
- 优点：内存占用较少，没有多余的key
- 缺点：
  - 实现复杂
  - 存在误判可能（不存在是真不存在，存在是不一定存在）

下面为上面两种方案的图解：

解决商铺缓存的缓存穿透问题

    public Result queryById(Long id) {
        //1. 从Redis中查询商铺缓存
        String shopJson = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id);
        //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 = this.getById(id);
        if(shop==null){
            stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id,"",CACHE_NULL_TTL,TimeUnit.MINUTES);
            //5. 数据库中查询失败，直接返回
            return Result.fail("店铺不存在");
        }
        //6. 数据库中查询成功，将数据缓存到Redis中
        stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id,JSONUtil.toJsonStr(shop),CACHE_SHOP_TTL, TimeUnit.MINUTES);
        return Result.ok(shop);
    }

其实布隆过滤和设置空值都是相对被动的解决方案，都是别人发起错误请求后，我们想办法拦截，我们也可以主动采取一些措施

增加 id 的复杂度，避免被猜测 id 的规律
加强用户权限校验
做好热点参数的限流

缓存雪崩

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

图解示意：

解决方案：

给不同的key的TTL添加随机值，方式Redis缓存的Key同时失效。
利用Redis集群提高服务的可用性（Redis哨兵集群，当一个主Redis宕机后，哨兵会选择一个从Redis替代他）
给缓存业务添加降级限流策略
给业务添加多级缓存：比如在1：Nginx做缓存==>2：Redis ==>3：数据库缓存

缓存击穿

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

很多个线程来访问，并且在缓存中都没有查询到，并且查询数据库的时间很长，就会给数据库带来很大压力。

常见的解决方案：

互斥锁
- 缺点：会存在死锁状态，性能降低
逻辑过期

不设置TTL，存在缓存击穿就是因为Key的TTL过期，将Key永远保存在缓存当中。

当线程4在线程2重置了过期时间后，再去查询缓存，就会命名更新后的缓存。

两种解决方案对比：

解决方案	优点	缺点
互斥锁	没有额外的内存消耗、保证一致性、实现简单	线程需要等待，性能受影响；可能有死锁的风险
逻辑过期	线程无需等待，性能较好	不保证一致性、有额外内存消耗、实现复杂

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

可以用 setnx 命令来做互斥锁

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

高并发的测试需要用到 jmeter 测试工具，或者Apifox也可以

基于逻辑过期解决缓存击穿问题

首先要创建一个预期的过期时间字段，我们要保证尽量不修改原来的代码，所以创建一个RedisData类

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

封装一个保存逻辑过期时间的方法

/**
 * 使用逻辑过期解决缓存击穿问题
 */
public void saveShop2Redis(Long id, Long expireSeconds) {
    // 查询店铺id
    Shop shop = getById(id);

    // 封装过期时间
    RedisData redisData = new RedisData();
    redisData.setData(shop);
    redisData.setExpireTime(LocalDateTime.now().plusSeconds(expireSeconds));
    // 设置进redis
    stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(redisData));
}

private final static ExecutorService CACHE_REBUILD_EXECUTOR = Executors.newFixedThreadPool(10);

    /**
     * 逻辑过期解决缓存击穿问题
     * @param id
     * @return
     */
    public Shop queryWithLogicalExpire(Long id) {
        // 1. 从Redis中查询店铺id
        String shopJson = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id);
        // 2. 判断Redis中是否存在该店铺
        if (StrUtil.isBlank(shopJson)) {
            // 店铺不存在
            return null;
        }
        // 命中，需要先把json反序列化未对象
        // RedisData redisData = JSONUtil.toBean(shopJson, new TypeReference>() {}, false);
        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;
        }
        System.out.println(LocalDateTime.now());
        // 已过期，需要缓存重建
        // 重建 1.获取互斥锁
        String lockKey = LOCK_SHOP_KEY + id;
        boolean isLock = tryGetLock(lockKey);
        //  2.判断是否获取成功
        if (isLock) {
            String shopJsonAgain = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id);
            //2.判断缓存是否命中
            if (StrUtil.isBlank(shopJsonAgain)) {
                //3.缓存命中直接返回
                return null;
            }
            //     3.成功需要开始额外的线程去数据库里查询
            CACHE_REBUILD_EXECUTOR.submit(() -> {
                try {
                    this.saveShop2Redis(id, 20L);
                } catch (Exception e) {
                    throw new RuntimeException(e);
                } finally {
                    //释放锁
                    tryDeleteLock(lockKey);
                }
            });
        }
        // 返回查询到的数据
        return shop;
    }

这个20秒是为了方便测试数据用的，按理来说应该是几十分钟，所以大家测试的时候不用测试10000条以上的线程，要不然容易报下面的错误

大家在看这个 jmeter 的响应数的时候，中文可能会乱码，大家可以看这篇文章https://www.cnblogs.com/xiaxiaoxu/p/9607017.html，里面有两种方法解决

封装缓存工具类

将在实现类中是业务逻辑进行封装到一个缓存工具类中，包括了缓存穿透、以及缓存击穿。

@Component
public class CacheClient {

    @Resource
    private StringRedisTemplate stringRedisTemplate;

    public void set(String key, Object value, Long time, TimeUnit unit){
        stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(value),time,unit);
    }

    public void setWithLogical(String key, Object value, Long time, TimeUnit unit){
        // 设置逻辑过期
        RedisData redisData = new RedisData();
        redisData.setData(value);
        redisData.setExpireTime(LocalDateTime.now().plusSeconds(unit.toSeconds(time)));
        //  写入Redis
        stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(redisData));
    }

    public <R,ID> R queryWithPassThrough(String keyPrefix, 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)) {
            //3.缓存命中直接返回
            return   JSONUtil.toBean(json, type);
        }
        // 判断命中的是否是空值
        if(json!=null){
            return null;
        }
        //4.缓存未命中，根据商铺id查询数据库
        R r = dbFallback.apply(id);
        if(r==null){
            stringRedisTemplate.opsForValue().set(key,"",CACHE_NULL_TTL,TimeUnit.MINUTES);
            //5. 数据库中查询失败，直接返回
            return null;
        }
        //6. 数据库中查询成功，将数据缓存到Redis中
        this.set(key,r,time,unit);
        return r;
    }
    private static  final ExecutorService CACHE_REBUILD_EXECUTOR = Executors.newFixedThreadPool(10);

    public <R,ID> R queryWithLogicalExpire(String keyPrefix,ID id,Class<R> type,Function<ID,R> dbFallback,
                                           Long time, TimeUnit unit){
        //1. 从Redis中查询商铺缓存
        String key=keyPrefix+id;
        String json = stringRedisTemplate.opsForValue().get(key);
        //2.判断缓存是否命中
        if (StrUtil.isBlank(json)) {
            //3.缓存未命中直接返回
            return null;
        }
        // 命中，需要先把json反序列化未对象
        RedisData redisData = JSONUtil.toBean(json, RedisData.class);
        R r = JSONUtil.toBean((JSONObject) redisData.getData(), type);
        LocalDateTime expireTime = redisData.getExpireTime();
        // 判断是否已经过期
        if(expireTime.isAfter(LocalDateTime.now())){
            //未过期
            return r ;
        }
        System.out.println(LocalDateTime.now());
        // 已过期，需要缓存重建
        // 重建 1.获取互斥锁
        String lockKey = LOCK_SHOP_KEY + id;
        boolean isLock = tryLock(lockKey);
        //     2.判断是否获取成功
        if(isLock){
            String shopJsonAgain = stringRedisTemplate.opsForValue().get(key);
            //2.判断缓存是否命中
            if (StrUtil.isBlank(shopJsonAgain)) {
                //3.缓存命中直接返回
                return null;
            }
            //     3.成功需要开始额外的线程去数据库里查询
            CACHE_REBUILD_EXECUTOR.submit(()->{
                try {
                    R r1 = dbFallback.apply(id);
                    this.setWithLogical(key,r,time,unit);
                } catch (Exception e) {
                    throw new RuntimeException(e);
                }finally {
                    //释放锁
                    unlock(lockKey);
                }
            });
        }
        // 返回查询到的数据
        return r;
    }
    private boolean tryLock(String key){
        Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.SECONDS);
        // 这里用到了一个 BooleanUtil 将 Boolean类型的 flag 转换为 boolean，如果直接返回Boolean类型的 flag，会自动拆箱，可能会出现null
        return BooleanUtil.isTrue(flag);
    }

    private void unlock(String key){
        stringRedisTemplate.delete(key);

    }
}

优惠券秒杀业务

全局唯一ID

为什么订单的id不使用自增呢？

id的规律性太明显（用户会根据id的规律猜测到信息）
受单表数据量的限制：会出现ID重复
当使用分布式系统，表进行拆分，id可能会重复

==全局 id 处理器：是一种在分布式系统下用来生产全局唯一ID的工具，==一般满足下列特征：

唯一性：
高可用（用户任何时候来生成 id,都要可以生成 id ）
高性能
递增性：整体的id变大
安全性：会给用户猜测到数据（比如出单多少）

用Redis来实现全局 id 处理器

递增性，唯一性（Redis中的string有一个increase命令，可保证唯一）
高可用（Redis的集群方案，主从方案，哨兵方案）
高性能（Redis的性能比数据库好很多）
安全性（可以不使用Redis自增的数值，可以拼接一些其他的信息）

使用Long类型，8位，64bit

全局 ID的组成部分

符号位：1 bit，永远为0
时间戳：31 bit，以秒为单位，可以使用69年（雪花算法是以毫秒为单位，41bit位也是用69年，毫秒和秒是1000的进制，1000相当于1024，就是10个 bit）
序列号：32 bit，秒内的计数器，可以支持每秒产生 2^32个不同ID

看到这里，可能很多朋友会感觉与雪花算法比较像，确实大致上是比较像的，但是还是有很多不同，具体的大家可以看这篇文章 https://zhuanlan.zhihu.com/p/85837641

@Component
public class RedisIdWorker {

    /**
     * 开始的时间戳（2022年1月1日0时0分0秒）
     */
    @Resource
    private StringRedisTemplate stringRedisTemplate;
    private static final long BEGIN_TIMESTAMP=1640995200;

    private static final int COUNT_BITS=32;
    //不同的业务，用不同的自增策略
    public long nextId(String keyPrefix){
        // 1.生成时间戳
        LocalDateTime now = LocalDateTime.now();
        long nowSecond = now.toEpochSecond(ZoneOffset.UTC);
        long timestamp = nowSecond - BEGIN_TIMESTAMP;
        // 2.生成序列号,
        // 2.1 获取当前日期，精确到天，如果按月的话，yyyy:MM:dd就好了，redis的key可以按冒号自动分层
        String date = now.format(DateTimeFormatter.ofPattern("yyy:MM:dd"));
        // 不会出现null，因为 increment命令当key不存在时，会自动创建
        long count = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix + ":" + date);
        // 3.拼接并返回
        // 时间戳向左移动32位，为序列号留出32位,然后留出来的32位都是0，然后进行或运算，
        // 与0做或运算就相当于把这个数本身保留下来了(梦回计算机导论)
        return timestamp << COUNT_BITS | count;
    }

    // 生成一个任意时间的时间戳，然后ID
    public static void main(String[] args) {
        LocalDateTime time = LocalDateTime.of(2023, 1, 1, 0, 0, 0);
        long second = time.toEpochSecond(ZoneOffset.UTC);
        System.out.println(second);
    }
}

测试 ID 生成器（虽然只是给测试方法，但里面还是提到了很多并发操作的知识）

    private ExecutorService es = Executors.newFixedThreadPool(500);  
	@Test
    void testId() 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()，直接获取时间，因为上面这个for循环只是将300的任务提交到线程池了，
        // 但是提交完后，线程还没有做完，就直接获取时间，得到的是提交消耗的时间
        // latch.await()是会阻塞线程，直到执行了n次countDown才会释放线程。
        latch.await();
        long end = System.currentTimeMillis();

        System.out.println("time="+(end-begin));
    }

关于具体的 await 和 countDown 操作大家可以看这篇文章https://blog.csdn.net/u011441473/article/details/103072449

全局唯一ID生成策略

UUID
Redis自增
snowflake算法
数据库自增

添加秒杀优惠券

其实这个接口黑马给的代码里面直接有了，业务也不复杂，是常见的业务，在这里就不细说了，

唯一一个要注意的点就是这个添加秒杀优惠券前端没有实现，可以通过接口文档或者 postman 进行实现下面是一个秒杀优惠券的例子，大家要把时间设置为在你当前时间的后面，要不然前端是不会显示的

{
    "shopId":1,
    "title":"100元代金券",
    "subTitle":"周一至周五均可使用",
    "rules":"全场通用\\n无需预约\\n可无限叠加\\不兑现、不找零\\n仅限堂食",
    "payValue":8000,
    "actualValue":10000,
    "type":1,
    "stock":100,
    "beginTime":"2023-03-15T22:09:17",
    "endTime":"2023-03-20T12:09:04"
}

实现优惠券秒杀的下单功能

下单前需要判断两点

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

这个下单还只是正常的业务，难的再后面

@Resource
    private ISeckillVoucherService seckillVoucherService;

    @Resource
    private RedisIdWorker redisIdWorker;
    @Transactional(rollbackFor = Exception.class) // 多表操作，最好添加一个事务，防止出现错误，好回滚事务
    @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();
        long orderId = redisIdWorker.nextId("order");
        // 添加订单id
        voucherOrder.setId(orderId);
        // 添加用户id
        Long userId = UserHolder.getUser().getId();
        voucherOrder.setUserId(userId);
        // 添加优惠券id
        voucherOrder.setVoucherId(voucherId);

        this.save(voucherOrder);
        return Result.ok(orderId);
    }

超卖问题

基于上面的代码，我们模拟两百个用户来抢购这个优惠券（这个接口请求前要求登录，所以我们要在请求头中加上token）

最后的结果我们去数据库看一下，出现了负数。

当线程1来查库存的时候，它查到库存是 1 ，就在这时候线程2来查库存，它查到的也是1，线程2查完后，线程1拿它刚查到的库存进行判断，大于0进行扣减。线程1 扣减完，线程2也根据它查到的库存进行判断，也大于0进行扣减，所以这时候库存就变为了-1。这就是出现多线程的高并发的安全问题。

悲观锁与乐观锁

为了解决这种问题，我们要去加锁。锁有两种（设计理念）：悲观锁和乐观锁。

悲观锁：

认为线程安全问题一定会发生，因此在操作数据之前先获取锁，确保线程串行执行
Synchronized，Lock都属于悲观锁
缺点：性能一般
优点：简单粗暴

乐观锁：

认为线程安全问题不一定会发生，因此不加锁，只是在更新数据时去判断有没有其他线程对数据做了修改
如果没有修改则认为是安全的，自己更新数据
如果已经被其他线程修改说明发生了安全问题，此时可以重试或抛出异常
优点：性能好
缺点：存在成功率低

乐观锁的解决线程安全问题

关键在于进行判断之前查询到的数据是否又被其他的线程修改过。

可以通过以下的两种方案：

版本号法
1. 当线程1进行查询时会查询到当前的版本version和票数stock，也就是线程1已经获得到了改版本号和现有的票数
2. 则此时线程2也进来查询库存，也会得到现在的版本号和票数（因为目前线程1还没有进行扣减）
3. 然后线程1就会对票数进行判断，大于0则进行扣减，扣减时要判断id以及版本号是否和查询到的版本号相同，相同则扣减成功，而且版本号+1，反之失败。
4. 然后线程2再进判断当前的票数是否大于0（是否还有票卖），有则进行票数减一，扣减时同样要判断id和版本号，就会发现此时的版本号已经不一样了，就不能进行扣减，这样解决了线程之间的安全问题
- 版本号法就是在原来的表中加入一个 version字段来控制版本，每次扣减的时候不仅要更新库存，还要更新版本，并且还要判断版本是否和先前查询的版本号是否一致，一致才可以更新。但这个方法还增加额外的内存消耗，其实我们也可以直接用 stock 当做版本号来使用，由此我们也来到了第二个方案 (CAS方案)
CAS方案（Compare And Set）
- 其实这个方案的思想跟第一个方案的思想是一致的，将库存是否变化用做控制条件

其实代码修改很简单：

// 6.扣减库存
boolean success = seckillVoucherService.update()
        .setSql("stock = stock - 1") // 乐观锁 set stock = stock - 1
        .eq("voucher_id", voucherId).eq("stock", 0) // where id = ? and stock > 0
        .update();

改成这样就可以了。但是这样会有一个问题，当100个线程同时来抢库存，第一个库存抢完后，修改了库存，但是其他的线程判断发现此时的库存跟他们刚才查到的不一样了，于是他们都放弃了更新。

这就是问题所在，错误率太高，其实我们更新的时候只要判断库存大于0就可以了，即使来了200个线程一起来抢，当抢完后，就会发现库存为0了，就会放弃。更改的代码如下

        boolean success = seckillVoucherService.update()
                .setSql("stock=stock-1").eq("voucher_id", voucherId).gt("stock",0).update();// 大于等于0

结果可以看到200个线程，异常率为50%，说明100个线程成功了。

数据库的数据也能对上了。

实现一人一单

因为秒杀优惠券是一个比较重要的商品，他不可能让一个人买100份，所以针对重要物品，要实现一人一单的功能，第一个版本就是简单的再增加一个判断。

        int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
        if(count>0){
            return Result.fail("用户已经购买过一次");
        }

但是这样写，不用猜就知道肯定有问题，我们来看一下数据库

我们可以看到库存变成了90，订单表新增了10条数据，这个跟超卖问题差不多吧，就是那个同一时间，多个线程在判断，判断成功后，都去执行操作了，这样肯定不行，所以我们要给他加锁。

但是，我们这里要先想一下，还能用乐观锁吗？乐观锁是当数据发生不一致的时候再加锁，而我们这对于一人一单就没有做更新操作，我们就是获取数据，然后判断数据。我们的问题是，有多个线程同时获取数据，他们不可以同时获取数据。所以乐观锁不是很好使，我们只好用悲观锁了。

// ctrl+alt+m,实现将代码块快速封装为一个函数

//我们现在把 synchronized 加在了方法上，那锁的是this，也就是对当前对象加锁，但是这每个线程肯定要
//创建不同的对象，所以synchronized加在这里不是很合适
    private synchronized Result getResult(Long voucherId) {
        Long userId = UserHolder.getUser().getId();
        // 判断一人一单
        int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
        if(count>0){
            return Result.fail("用户已经购买过一次");
        }
        // 5.扣除库存
        boolean success = seckillVoucherService.update()
                .setSql("stock=stock-1").eq("voucher_id", voucherId).gt("stock",0).update();
        if(!success){
            return Result.fail("库存不足");
        }
        // 6.创建订单
        VoucherOrder voucherOrder = new VoucherOrder();
        long orderId = redisIdWorker.nextId("order");
        // 添加订单id
        voucherOrder.setId(orderId);
        // 添加用户id

        voucherOrder.setUserId(userId);
        // 添加优惠券id
        voucherOrder.setVoucherId(voucherId);

        this.save(voucherOrder);
        return Result.ok(orderId);
    }

那我们是就要减小锁的范围，要对同一个用户加锁，可以对用户 id 加锁

	@Transactional
    // ctrl+alt+m,实现将代码块快速封装为一个函数
    public  Result getResult(Long voucherId) {
        Long userId = UserHolder.getUser().getId();
//我们对userId加锁，把他用toString转成一个字符串来进行加锁。但是这样就可以了吗？
//还不行，因为，Long类型的toString底层是new 了一个String的，等于说还是比较对象的地址，那不行
//所以我们要用一个方法 intern(),获取字符串的值，这样每次来比较的就是比较值了，我们可以给他加上
        synchronized (userId.toString()) {
            // 判断一人一单
            int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
            if (count > 0) {
                return Result.fail("用户已经购买过一次");
            }
            // 5.扣除库存
            boolean success = seckillVoucherService.update()
                    .setSql("stock=stock-1").eq("voucher_id", voucherId).gt("stock", 0).update();
            if (!success) {
                return Result.fail("库存不足");
            }
            // 6.创建订单
            VoucherOrder voucherOrder = new VoucherOrder();
            long orderId = redisIdWorker.nextId("order");
            // 添加订单id
            voucherOrder.setId(orderId);
            // 添加用户id

            voucherOrder.setUserId(userId);
            // 添加优惠券id
            voucherOrder.setVoucherId(voucherId);

            this.save(voucherOrder);
            return Result.ok(orderId);
        }
    }

但是上面的代码就解决问题了吗？还没有，因为我们 getResult 上面有@Transactional事务注解，当我们这个操作都完成了，但是这个 getResult这个方法没结束，那数据还是没提交到数据库中，那此时如果再有一个线程进入的话，那还是会出现并发问题，也就是 synchronized 锁小了，要锁这个方法。

        // 这个是seckillVoucher方法的后面的部分，我们把synchronized   加在了方法上，而事务是在
        // 方法上的，那只要进来这个synchronized的，那数据库的数据一定是提交过的。
        Long userId = UserHolder.getUser().getId();
        synchronized (userId.toString().intern()) {
            return getResult(voucherId);
        }

以为到这里就结束了吗？还没有，我们是把 @Transactional加到了 getResult上了，但是没有加到seckillVoucher这个方法上，但是外部是调这个函数的，那 getResult上的@Transactional就会失效，这是事务注解失效的一个最常见场景，这里就要提到 @Transactional的原理和源码了，我这块也学的不好，建议大家看下面这篇文章，这篇文章讲的很好，跟踪源码讲的，能力强的小伙伴也可以自己去试着跟踪源码看一下https://blog.csdn.net/hollis_chuang/article/details/115713374（这里还是推荐大家自己跟踪一下源码，我看了2遍没看懂，还得是跟踪源码）

简单来说就是：VoucherOrderServiceImpl这个 bean上只要有一个方法有 @Transaction，那么Spring就会为其创建代理对象（整个事务的开始和结束都由代理对象来调用），但是创建了代理对象也不一定会代理方法。

然后还需要找一个方法上的@Transactional注解信息，没有的话就不执行代理@Transactional对应的代理逻辑，直接执行方法。没有了@Transactional注解代理逻辑，就无法开启事务。这里说的挺懵的，还是打断点追踪源码吧

那么针对我们这个问题，实际上就是在我们的 bean 刚要加载的时候，spring 会扫描看看哪个类的哪个方法带有 @Transactional注解，在我们这就是 getResult 上面由这个注解，所以 spring 会创建VoucherOrderServiceImpl这个类的代理对象，然后当我们外面调用 seckillVoucher这个方法时，本来是要VoucherOrderServiceImpl的一个对象来调用的，对吧，但是spring已经为我们这个类创建了代理对象了，那么 spring会让这个代理对象来直接调用这个函数吗？根据上面所说，是不会的，spring还要检查一下你调用的这个方法是否有事务注解，如果调用的这个方法上没有事务注解的话，那么spring也是不会让代理对象去执行的。还是让原对象执行，那我们知道，seckillVoucher这个方法里面调用了 getResult这个方法，那么我们也可以知道调用 getResult的就是 this，即也是VoucherOrderServiceImpl这个类的对象。那么为了让他的代理对象来去调用这个方法，我们的代码如下

        synchronized (userId.toString().intern()) {
            // 获取到当前的代理对象
            IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
            return proxy.createVoucherOrder(voucherId);
        }

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

//暴露代理对象
@EnableAspectJAutoProxy(exposeProxy = true)

集群下的并发安全问题

一人一单在集群的情况下可能出现的问题：

同一个人会出现多次添加订单的操作。

分布式锁

分布式锁介绍

分布式锁：满足分布式系统或集群模式下多进程可见并且互斥的锁。只有一个进程能访问到，其他的需要等待。

多线程可见：当线程1获取到锁之后，其他的线程都能到它已经获取到锁
互斥：只能一个线程获取到锁
高可用：很多情况下每个线程获取锁的情况都是能获取到锁的
高性能：获取锁的（动作）时候
安全性：会不会产生死锁？

要满足以上的节点，就要将多个JVM中的多个线程使用同一个监视器

分布式锁的实现

实现的核心就是多进程之间互斥，可以通过以下的三种方式：

	MySQL	Redis	Zookeeper
互斥	使用MySQL本身的互斥锁机制	利用Setnx（不存在则创建）命令形成互斥	利用节点的唯一性和有序性实现互斥
高可用	好	好	好
高性能	一般	高	一般
安全性	断开链接，自动释放锁	一般（会出现死锁，利用锁超时时间，到期释放）	断开节点，断开链接自动释放

安全性角度：Redis与其他两个来说没有那么好
可用性、性能高角度：Redis是最好的

Redis实现分布式锁

获取锁

互斥：确保只有一个线程获取倒锁

非阻塞形式：尝试获取锁一次，成功返回true，失败返回false

setnx lock1 "thread1"
expire lock1 10 # 10秒后过期
# 原子性操作，就是将以上的两个合并成一条命令
set lock2 thread2 ex 20 nx # ex为过期时间 nx为不存在则创建，类似setn

释放锁

手动释放，删除锁
```
del lock1
```
超时释放：给锁设置一个过期时间，避免服务宕机引起死锁

Redis实现分布式锁的执行流程

但是以上的流程是会出现问题

由于线程1的业务阻塞，导致了改锁提前释放（业务还没有执行完成，锁就被释放了）
由于线程1的业务阻塞的原因会执行很久，当执行完业务之后，会直接释放锁，但是此时的锁已经是其他线程的锁

解决方案

就是释放锁的时候要判断改锁是不是自己的锁

在获取锁的时候存入线程标识（使用UUID）
- 锁的标识一致则释放，都在不释放

private String name;
private StringRedisTemplate stringRedisTemplate;

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

private static final String KEY_PREFIX = "lock:";
private static final String ID_PREFIX = UUID.randomUUID().toString(true) + "-";
@Override
public boolean tryLock(long timeoutSec) {
    // 获取线程标示
    String threadId = ID_PREFIX + Thread.currentThread().getId();
    // 获取锁
    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);
    }
}

到此还是会出现问题

当锁将要（释放之前）进行释放的时候遇到线程阻塞，此时其他的线程就会获取到锁，当阻塞执行结束，将会释放掉被人的锁

使用Redis的原子性

原子性

解决方案

原子性：获取锁的标识和释放锁的标识要一致

使用lua脚本，在一个脚本中编写多条Redis命令，确保多条命令执行时的原子性

Lua教程

比如设置值

eval "return redis.call("set","name","shier")" 0

不把KEY、和Value写死，就会把key类型参数存入KEYS数组中，其他参数会放入ARGV数组

eval "return redis.call("set",KEYS[1],ARGV[1])" 1 name shier

释放锁lua脚本

-- 比较线程标示与锁中的标示是否一致
if(redis.call('get', KEYS[1]) ==  ARGV[1]) then
    -- 释放锁 del key
    return redis.call('del', KEYS[1])
end
return 0

Java中执行Lua脚本，释放脚本

调用的是以下的方法

public <T> T execute(RedisScript<T> script, List<K> keys, Object... args) {
    return this.scriptExecutor.execute(script, keys, args);
}
RedisScript<T> script：传入的是指定lua脚本
List<K> keys ：传入的是lua脚本中的到KEYS数组
Object... args：一个可变的参数列表：传入的是锁的标识和线程id

private static final DefaultRedisScript<Long> UNLOCK_SCRIPT; // 动态获取到释放锁的lua脚本
static {
    UNLOCK_SCRIPT = new DefaultRedisScript<>();
    UNLOCK_SCRIPT.setLocation(new ClassPathResource("unlock.lua")); // 找到lua脚本的位置
    UNLOCK_SCRIPT.setResultType(Long.class);
}

@Override
public void unlock() {
    // 调用lua脚本
    stringRedisTemplate.execute(
            UNLOCK_SCRIPT,
            Collections.singletonList(KEY_PREFIX + name),
            ID_PREFIX + Thread.currentThread().getId());
}

Redis-setnx实现分布式锁总结

实现思路

利用set nx 获取锁，并设置过期时间，保存线程的标识
释放锁时先判断线程标识是否一致，一致则删除锁

特性

set nx满足互斥性
利用set nx 保证故障锁依然能释放，避免死锁，提高安全性
利用Redis集群保证高可用和高并发特性

Redisson实现分布式锁

基于setnx实现的方式存在以下的问题

不可重入：同一个线程无法多次获取同一把锁。
不可重试：获取锁只尝试一次就返回false，没有重试机制。
超时释放：锁超时释放虽可避免死锁，但若是业务执行的时间过长，也会导致锁释放，存在安全隐患。
主从一致性：如果Redis提供了主从集群，主从同步存在延迟，当主宕机时，如果从并同步主中的锁数据，则会出现锁实现。（写的在主节点，读取是在从节点，主从要实现同步）

为什么要Redisson？

因为Redisson能更好的解决以上存在的问题。

Redisson介绍

Redisson是一个基于Redis基础上实现的Java驻内存数据网格（In-Memory Date Grid）

它充分利用了 Redis 键值数据库提供的一系列优势，基于 Java 实用工具包中常用接口，为使用者提供了一系列具有分布式特性的常用工具类，让使用 Redis 更加简单、便捷，从而让使用者能够将更多精力集中到业务逻辑处理上。
Redisson并不仅仅是一个 Redis 客户端，它还实现了很多具有分布式特性的常用工具类，例如分布式锁、布隆过滤器等。除此之外，Redisson 支持异步、反应式编程等特性，以及多种序列化方式（Jackson、Avro、Smile 等）和 RDB 持久化方式。
使用 Redisson 在分布式应用中进行锁的控制可以避免出现锁竞争等并发问题，也非常容易上手并且使用方便。Redisson 的文档详尽全面，提供了很多使用示例和配置项。无论是在单机 Redis 中使用还是在 Redis 集群中使用都有很好的适配性。

Redisson 入门学习

需要到什么组件，都是先导入对应maven

<!--redisson-->
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.13.6</version>
</dependency>

编写一个Redisson的配置类，设置好服务器端的ip地址，和redis密码

@Configuration
public class RedissonConfig {

    @Bean
    public RedissonClient redissonClient() {
        // 配置
        Config config = new Config();
        // 配置单节点的服务器地址
        config.useSingleServer().setAddress("redis://192.168.20.144:6379").setPassword("123456");
        // 创建RedissonClient对象
        return Redisson.create(config);
    }
}

Redisson可重入锁原理

Redisson的可重入锁主要使用的Hash数据结构，Key中存放的是锁的key，Value中存放的是线程标识和创建锁的次数，主要的结构如下

以下是执行的流程：

我们在lua脚本中编写获取锁程序，不过这些代码在Redssion源码中已经写好了的

我们可以在写一个测试类来测试一下以上的流程是否符合预期

@Slf4j
@SpringBootTest
class RedissonTest {

    @Resource
    private RedissonClient redissonClient;

    private RLock lock;

    @BeforeEach
    void setUp() {
        lock = redissonClient.getLock("order");
    }

    @Test
    void method1() throws InterruptedException {
        // 尝试获取锁
        boolean isLock = lock.tryLock(1L, TimeUnit.SECONDS);
        if (!isLock) {
            log.error("获取锁失败 .... 1");
            return;
        }
        try {
            log.info("获取锁成功 .... 1");
            method2();
            log.info("开始执行业务 ... 1");
        } finally {
            log.warn("准备释放锁 .... 1");
            lock.unlock();
        }
    }
    void method2() {
        // 尝试获取锁
        boolean isLock = lock.tryLock();
        if (!isLock) {
            log.error("获取锁失败 .... 2");
            return;
        }
        try {
            log.info("获取锁成功 .... 2");
            log.info("开始执行业务 ... 2");
        } finally {
            log.warn("准备释放锁 .... 2");
            lock.unlock();
        }
    }
}

预取效果一致：

Redission锁重试和看门狗机制

获取锁脚本执行流程

整如下图为Redisson整个执行流程的过程，右侧为释放锁执行流程

Redisson分布式锁的原理

视频地址详解

可重入：Redisson中使用hash结构代替了Redis的String结构，hash结构能记录到传入的key、线程id和重入次数。
可重试：利用信号量和PubSub功能实现等待、唤醒、获取失败的重试机制，超过了等待时间就不再等待。
超时释放锁：利用看门狗机制，每隔一段时间（releaseTime / 3）就会重置超时时间。

Redisson分布式锁MutilLock（连锁策略）原理-解决主从一致性

连锁策略：不再有主从节点，都获取成功才能获取锁成功，有一个节点获取锁不成功就获取锁失败

连锁策略的好处：

解决了主从节点之间单个节点出现问题时，其他的节点会获得锁，就会出现线程的安全问题，也解决了主从同步时的延迟问题。
连锁策略通过建立多个独立的节点，单个独立节点之间也可以建立主从的关系，当一个节点出现宕机时，新的线程想要获取锁是获取不到的，必须要同时获取到全部的上一个线程当中的所有独立节点，才算是获取锁成功。
- 主节点：将应用发送过来的内容写入，然后进行主从同步
- 从节点：就是读取主节点当中的数据

如果多个主节点保证锁的话，一个主节点宕机了，其它线程只能获得一个新主节点的锁，获取不到其它两个锁，还会获取失败。这里主要是防止主节点宕机后，其它线程获得新主节点的锁，引起线程安全问题

分布式锁总结

不可重入Redis 分布式锁
- 原理：利用 setnx 的互斥性；利用 ex 避免死锁；释放锁时判断线程标示
- 缺陷：不可重入、无法重试、锁超时失效
可重入的 Redis 分布式锁
- 原理：利用 hash 结构，记录线程标示和重入次数；利用 watchDog 延续锁时间；利用信号量控制锁重试等待
- 缺陷：Redis 宕机引起锁失效问题
Redisson 的 multiLock连锁（最安全）
- 原理：多个独立的 Redis 节点，必须在所有节点都获取重入锁，才算获取锁成功
- 缺陷：运维成本高、实现复杂

Redis 优化秒杀

为避免所有操作都在数据库上执行，分离成两个线程，一个线程判断用户的购买资格，发现用户有购买资格后再开启一个独立的线程来处理耗时较久的减库存、写订单的操作。
可以将耗时较短的两步操作放到 Redis 中，在 Redis 中处理对应的秒杀资格的判断。Redis 的性能是比 MySQL 要好的。此外，还需要引入异步队列记录相关的信息。

分析图如下：

将优惠卷库存、一人一单在redis中进行操作，redis的读写操作是相当快的，这样就可以提升性能。

使用Redis中的String数据结构来保存库存中优惠卷的id和value，使用Set数据结构记录一人一单的行为，保证了key唯一，而且可以有多种优惠卷。redis部分处理逻辑， Lua脚本封装操作保证原子性， redis这里选择的存储类型为set，因为key不能重复，而set恰好是无序不重复的

执行的流程图如下：

VoucherServiceImpl

// 保存秒杀库存到Redis中
stringRedisTemplate.opsForValue().set(SECKILL_STOCK_KEY + voucher.getId(), voucher.getStock().toString());

seckill.lua

-- 1.参数列表
-- 1.1.优惠券id
local voucherId = ARGV[1]
-- 1.2.用户id
local userId = ARGV[2]
-- 1.3.订单id
local orderId = ARGV[3]

-- 2.数据key
-- 2.1.库存key
local stockKey = 'seckill:stock:' .. voucherId
-- 2.2.订单key
local orderKey = 'seckill:order:' .. voucherId

-- 3.脚本业务
-- 3.1.判断库存是否充足 get stockKey
if(tonumber(redis.call('get', stockKey)) <= 0) then
    -- 3.2.库存不足，返回1
    return 1
end
-- 3.2.判断用户是否下单 SISMEMBER orderKey userId
if(redis.call('sismember', orderKey, userId) == 1) then
    -- 3.3.存在，说明是重复下单，返回2
    return 2
end
-- 3.4.扣库存 incrby stockKey -1
redis.call('incrby', stockKey, -1)
-- 3.5.下单（保存用户）sadd orderKey userId
redis.call('sadd', orderKey, userId)
-- 3.6.发送消息到队列中， XADD stream.orders * k1 v1 k2 v2 ...
redis.call('xadd', 'stream.orders', '*', 'userId', userId, 'voucherId', voucherId, 'id', orderId)
return 0

VoucherOrderServiceImpl

private static final DefaultRedisScript<Long> SECKILL_SCRIPT;

    static {
        SECKILL_SCRIPT = new DefaultRedisScript<>();
        SECKILL_SCRIPT.setLocation(new ClassPathResource("seckill.lua"));
        SECKILL_SCRIPT.setResultType(Long.class);
    }
    
    private static final ExecutorService SECKILL_ORDER_EXECUTOR = Executors.newSingleThreadExecutor();

    @PostConstruct
    private void init() {
        SECKILL_ORDER_EXECUTOR.submit(new VoucherOrderHandler());
    }

    private class VoucherOrderHandler implements Runnable {
        @Override
        public void run() {
            
        }


    private void createVoucherOrder(VoucherOrder voucherOrder) {
        Long userId = voucherOrder.getUserId();
        Long voucherId = voucherOrder.getVoucherId();
        // 创建锁对象
        RLock redisLock = redissonClient.getLock("lock:order:" + userId);
        // 尝试获取锁
        boolean isLock = redisLock.tryLock();
        // 判断
        if (!isLock) {
            // 获取锁失败，直接返回失败或者重试
            log.error("不允许重复下单！");
            return;
        }

        try {
            // 5.1.查询订单
            int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
            // 5.2.判断是否存在
            if (count > 0) {
                // 用户已经购买过了
                log.error("不允许重复下单！");
                return;
            }

            // 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) {
                // 扣减失败
                log.error("库存不足！");
                return;
            }

            // 7.创建订单
            save(voucherOrder);
        } finally {
            // 释放锁
            redisLock.unlock();
        }
    }

    @Override
    public Result seckillVoucher(Long voucherId) {
        Long userId = UserHolder.getUser().getId();
        long orderId = redisIdWorker.nextId("order");
        // 1.执行lua脚本
        Long result = stringRedisTemplate.execute(
                SECKILL_SCRIPT,
                Collections.emptyList(),
                voucherId.toString(), userId.toString(), String.valueOf(orderId)
        );
        int r = result.intValue();
        // 2.判断结果是否为0
        if (r != 0) {
            // 2.1.不为0 ，代表没有购买资格
            return Result.fail(r == 1 ? "库存不足" : "不能重复下单");
        }
        // 3.返回订单id
        return Result.ok(orderId);
    }

基于阻塞队列的异步秒杀存在哪些问题？

内存限制问题 —> 我们使用的是JDK里的阻塞队列，是基于JVM的内存，高并发海量请求下造成内存溢出还有服务宕机情况下内存数据丢失
数据安全问题

Redis消息队列

消息队列（Message Queue）：存放消息的队列，最简单的消息队列模型有以下的三个角色

消息队列：存储和管理消息，也称消息代理（Message Broker）（类似于快递收发室，这个收发室就是处理一些列的快递操作）
生产者：发送消息到消息队列（快递员运输快递）
消费者：从消息队列获取到消息并处理消息（我们去收发室取快递）

MQ是JVM以外的服务，不受JVM内存限制，且MQ中的所有消息会做持久化，这样即使重启或宕机，数据不会丢失。消息投递给消费者后需要消费者确认，未确认消息会一直存在下一次继续投递，确保消息至少被消费一次

基于List结构模拟消息队列

Redis的list结构是一个双向链表。（队列特点是先进先出的）

队列是入口和出口不在一边，因此我们可以利用：LPUSH 结合 RPOP、或者 RPUSH 结合 LPOP 来实现。
不过要注意的是，当队列中没有消息时 RPOP 或 LPOP 操作会返回 null，并不像 JVM 的阻塞队列那样会阻塞并等待消息。因此这里应该使用 BRPOP 或者 BLPOP 来实现阻塞效果。
- BLPOP / BRPOP：当有数据时就会读取，没有则会进入阻塞等待状态

基于 List 的消息队列优缺点

优点：

利用 Redis 存储，不受限于 JVM 内存上限
基于 Redis 的持久化机制，数据安全性有保证
可以满足消息有序性

缺点：

无法避免消息丢失
只支持单消费者

基本的点对点消息模型

PubSub（Public：发布，Subscribe：订阅）是 Redis 2.0 版本引入的消息传递模型。

顾名思义，消费者可以订阅一个或多个channel（频道），生产者向对应 channel 发送消息后，所有订阅者都能收到相关消息。

有以下的命令：

SUBSCRIBE channel [channel] ：订阅一个或多个频道
PUBLISH channel msg ：向一个频道发送消息
PSUBSCRIBE pattern[pattern] ：订阅与 pattern 格式匹配的所有频道
1. pattern – 通配符方式
  1. ?：匹配一个字符
  - h?llo：此处的? 就可以匹配一个不同的字母，比如会匹配到 hello、hallo、hhllo
  1. *：匹配多个字符
  - h?llo：此处的? 就可以多个相同字母，比如会匹配到 heeeello、haaaadllo、hhhhhllo
  1. ae：匹配括号内存在的字符
    - h[ae]llo：能匹配到hallo、hello，但不是匹配到hsllo

下面的消费者使用了一个通配符，可以订阅到所有的消息
上面的消费者只能订阅到queue频段的信息，* 能接受到更多的消息

基于 PubSub 的消息队列优缺点

优点：

采用发布订阅模型，支持多生产、多消费

缺点：

不支持数据持久化
无法避免消息丢失：发布的消息没有被订阅就会丢失
消息堆积有上限，超出时数据丢失。在消费者那里存储的缓存的有限的，超出了缓存的大小就会丢失数据。

基于Stream的消息队列

比较完善的消息队列模型

Stream是Redis5引入的一种新的数据类型，可以实现一个功能非常完善的消息队列。既然是数据类型，那么和之前的String等数据类型一样都支持持久化数据，并且都具有一定的安全性。

最主要的还是怎么进行发送消息和读取消息，通过以下的指令完成发送消息：

XADD ：发送（添加）消息

示例：

XADD root * name shier age 18
# 创建一个名为 root 的队列,并且发送一条消息，内容：{name=shier,age=18},id（也就是*那里）由redis自动生成。

XREAD ：读取消息
- 阻塞：一直处于阻塞状态，等有消息发送过来时才会被读取到。
```
XREAD COUNT 1 BLOCK 1000 STREAMS root $
```
- 当采用阻塞进行读取最新消息（$）时，会出现问题：当处理一条消息时，有又很多条消息到达队列，下次读取只会读取到最新的一条消息，就会溜掉中间的消息，出现漏读现象。

STREAM类型的消息队列中XREAD的特点：

消息可回溯（可以永久保存，持久化，每次读取都能读取到消息）
一个消息可以被多个消费者读取
消息可以被阻塞读取
消息会又漏读的风险

消费者组

消费者组（Consumer Group）：将多个消费者划分到一个组中，监听同一个队列。

消费者组具有以下的特点：

消息分流：队列中的消息会被分流给组内的不同消费者，而不是重复消费，从而加快消息处理的时间。
消息标识：消费者会维护一个标示，记录最后一个被处理的消息，哪怕消费者宕机重启，还会从标示之后读取消息，确保每一个消息都会被消费，就避免了漏读的情况。
消息确认：消费者获取消息后，消息处理pending（待处理）状态，并存入到一个待处理的列表pending-list中，当处理完成后需要通过XACK来确认消息，标记消息为已处理，才会从pending-list 移除。这样就能确保每一个消息都会至少的读取一次。

创建消费者组

XGROUP CREATE key groupName ID [MKSTREAM]

key：队列名称
groupName：消费者组名称
ID：起始ID标示，$ 表示最后一个消息（最新的消息），0代表第一个消息
MKSTREAM：队列不存在时自创建队列

删除消费者组

XGROUP DESTORY key groupName

从消费者读取组消息

XREADGROUP GROUP group consumer [COUNT count] [BLOCK milliseconds] STREAMS key [key ...] ID [ID ...]

group：消费组名称
consumer：消费者名称，不存在则会自动创建消费者
count：本次查询的最大数量
BLOCK milliseconds：当没有消息时最长等待时间
NOACK：无需手动ACK，获取消息后会自动确定
STRAMS key ：指定队列名称
ID：获取消息的起始ID
- ">"：读取消息队列中所有没有被消费的消息。从下一个未消费的消息开始
- 其它：根据指定id从pending-list中获取已消费但未确认的消息，例如0，是从pending-list中的第一个消息开始

确认消息指令

XACK key group ID [ID ...]

查看pending-list

XPENDING key group [start end count] [consumer]

STREAM类型消息队列的XREADGROUP命令特点：

消息可回溯
可以多消费者争抢消息，加快消费速度
可以阻塞读取
没有消息漏读的风险
有消息确认机制，保证消息至少被消费一次

Redis消息队列的对比

	List	PubSub	Stream
消息持久化	支持	不支持	支持
阻塞读取	支持	支持	支持
消息堆积处理	受限于内存空间，可以利用多消费者加快处理	受限于消费者缓冲区	受限于队列长度，可以利用消费者组提高消费速度，减少堆积
消息确认机制	不支持	不支持	支持
消息回溯	不支持	不支持	支持

最推荐的是Stream消息队列

基于Redis的Stream结构作为消息队列，实现异步秒杀下单

① 创建一个Stream类型的消息队列，名为stream.orders

XGROUP CREATE stream.orders g1 0 MKSTREAM

② 修改之前的秒杀下单Lua脚本，在认定有抢购资格后，直接向stream.orders中添加消息，内容包含voucherId、userId、orderId

-- 1.参数列表
-- 1.1.优惠券id
local voucherId = ARGV[1]
-- 1.2.用户id
local userId = ARGV[2]
-- 1.3.订单id
local orderId = ARGV[3]

-- 2.数据key
-- 2.1.库存key
local stockKey = 'seckill:stock:' .. voucherId
-- 2.2.订单key
local orderKey = 'seckill:order:' .. voucherId

-- 3.脚本业务
-- 3.1.判断库存是否充足 get stockKey
if(tonumber(redis.call('get', stockKey)) <= 0) then
    -- 3.2.库存不足，返回1
    return 1
end
-- 3.2.判断用户是否下单 SISMEMBER orderKey userId
if(redis.call('sismember', orderKey, userId) == 1) then
    -- 3.3.存在，说明是重复下单，返回2
    return 2
end
-- 3.4.扣库存 incrby stockKey -1
redis.call('incrby', stockKey, -1)
-- 3.5.下单（保存用户）sadd orderKey userId
redis.call('sadd', orderKey, userId)
-- 3.6.发送消息到队列中， XADD stream.orders * k1 v1 k2 v2 ...
redis.call('xadd', 'stream.orders', '*', 'userId', userId, 'voucherId', voucherId, 'id', orderId)
return 0

③ 项目启动时，开启一个线程任务，尝试获取stream.orders中的消息，完成下单

优惠卷处理：

    private class VoucherOrderHandler implements Runnable {
        @Override
        public void run() {
            while (true) {
                try {
                    // 1.获取消息队列中的订单信息 XREADGROUP GROUP g1 c1 COUNT 1 BLOCK 2000 STREAMS s1 >
                    List<MapRecord<String, Object, Object>> list = stringRedisTemplate.opsForStream().read(
                            Consumer.from("g1", "c1"), // GROUP g1 c1
                            StreamReadOptions.empty().count(1).block(Duration.ofSeconds(2)),//COUNT 1 BLOCK 2000
                            StreamOffset.create("stream.orders", ReadOffset.lastConsumed())//STREAMS s1 >
                    );
                    // 2.判断订单信息是否为空
                    if (list == null || list.isEmpty()) {
                        // 如果为null，说明没有消息，继续下一次循环
                        continue;
                    }
                    // 解析数据
                    MapRecord<String, Object, Object> record = list.get(0);
                    Map<Object, Object> value = record.getValue();
                    VoucherOrder voucherOrder = BeanUtil.fillBeanWithMap(value, new VoucherOrder(), true);
                    // 3.创建订单
                    createVoucherOrder(voucherOrder);
                    // 4.确认消息 XACK
                    stringRedisTemplate.opsForStream().acknowledge("s1", "g1", record.getId());
                } catch (Exception e) {
                    log.error("处理订单异常", e);
                    handlePendingList();
                }
            }
        }

        private void handlePendingList() {
            while (true) {
                try {
                    // 1.获取pending-list中的订单信息 XREADGROUP GROUP g1 c1 COUNT 1 BLOCK 2000 STREAMS s1 0
                    List<MapRecord<String, Object, Object>> list = stringRedisTemplate.opsForStream().read(
                            Consumer.from("g1", "c1"),
                            StreamReadOptions.empty().count(1),
                            StreamOffset.create("stream.orders", ReadOffset.from("0"))
                    );
                    // 2.判断订单信息是否为空
                    if (list == null || list.isEmpty()) {
                        // 如果为null，说明没有异常消息，结束循环
                        break;
                    }
                    // 解析数据
                    MapRecord<String, Object, Object> record = list.get(0);
                    Map<Object, Object> value = record.getValue();
                    VoucherOrder voucherOrder = BeanUtil.fillBeanWithMap(value, new VoucherOrder(), true);
                    // 3.创建订单
                    createVoucherOrder(voucherOrder);
                    // 4.确认消息 XACK
                    stringRedisTemplate.opsForStream().acknowledge("s1", "g1", record.getId());
                } catch (Exception e) {
                    log.error("处理订单异常", e);
                }
            }
        }
    }

达人探店

探店笔记

发布探店笔记

探店笔记类似点评网站的评价，往往是图文结合。对应的表有两个：

tb_blog：探店笔记表，包含笔记中的标题、文字、图片等

DROP TABLE IF EXISTS `tb_blog`;
CREATE TABLE `tb_blog`
(
    `id`          bigint(20) UNSIGNED                                            NOT NULL AUTO_INCREMENT COMMENT '主键',
    `shop_id`     bigint(20)                                                     NOT NULL COMMENT '商户id',
    `user_id`     bigint(20) UNSIGNED                                            NOT NULL COMMENT '用户id',
    `title`       varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci  NOT NULL COMMENT '标题',
    `images`      varchar(2048) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '探店的照片，最多9张，多张以\",\"隔开',
    `content`     varchar(2048) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '探店的文字描述',
    `liked`       int(8) UNSIGNED                                                NULL     DEFAULT 00000000 COMMENT '点赞数量',
    `comments`    int(8) UNSIGNED                                                NULL     DEFAULT NULL COMMENT '评论数量',
    `create_time` timestamp                                                      NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    `update_time` timestamp                                                      NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB
  AUTO_INCREMENT = 8
  CHARACTER SET = utf8mb4
  COLLATE = utf8mb4_general_ci
  ROW_FORMAT = Compact;

tb_blog_comments：其他用户对探店笔记的评价

查看探店笔记

在BlogContoller.java中创建一个方法

@Override
public Result queryBlogById(Long id) {
    // 1.查询blog
    Blog blog = getById(id);
    if (blog == null) {
        return Result.fail("笔记不存在！");
    }
    // 2.查询blog有关的用户
    queryBlogUser(blog);
    return Result.ok(blog);
}

控制层接口如下定义：

@GetMapping("/{id}")
public Result queryBlogById(@PathVariable("id") Long id) {
    return blogService.queryBlogById(id);
}

点赞功能

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

实现步骤：

① 给Blog类中添加一个isLike字段，标示是否被当前用户点赞

② 修改点赞功能，利用Redis的set集合判断是否点赞过，未点赞过则点赞数+1，已点赞过则点赞数-1

③ 修改根据id查询Blog的业务，判断当前登录用户是否点赞过，赋值给isLike字段

④ 修改分页查询Blog业务，判断当前登录用户是否点赞过，赋值给isLike字段

点赞排行榜

按照点赞时间先后排序，返回Top5的用户

	List	Set	SortedSet
排序方式	按添加顺序排序	无法排序	根据score值排序
唯一性	不唯一	唯一	唯一
查找方式	按索引查找或首尾查找	根据元素查找	根据元素查找

综合来看，这里选择SortedSet数据结构来进行排行榜（更加的符合需求）

使用SortedSet中的ZSCORE命令来查看每个元素对应的分数，来判断元素是否存在

实现方法：

@Override
public Result likeBlog(Long id) {
    // 1.获取登录用户
    Long userId = UserHolder.getUser().getId();
    // 2.判断当前登录用户是否已经点赞
    String key = BLOG_LIKED_KEY + id;
    Double score = stringRedisTemplate.opsForZSet().score(key, userId.toString());
    if (score == null) {
        // 3.如果未点赞，可以点赞
        // 3.1.数据库点赞数 + 1
        boolean isSuccess = update().setSql("liked = liked + 1").eq("id", id).update();
        // 3.2.保存用户到Redis的set集合  zadd key value score
        if (isSuccess) {
            stringRedisTemplate.opsForZSet().add(key, userId.toString(), System.currentTimeMillis());
        }
    } else {
        // 4.如果已点赞，取消点赞
        // 4.1.数据库点赞数 -1
        boolean isSuccess = update().setSql("liked = liked - 1").eq("id", id).update();
        // 4.2.把用户从Redis的set集合移除
        if (isSuccess) {
            stringRedisTemplate.opsForZSet().remove(key, userId.toString());
        }
    }
    return Result.ok();
}

点赞列表查询

控制层

@GetMapping("/likes/{id}")
public Result queryBlogLikes(@PathVariable("id") Long id) {
    return blogService.queryBlogLikes(id);
}

接口

Result queryBlogLikes(Long id);

接口实现类

@Override
public Result queryBlogLikes(Long id) {
    String key = BLOG_LIKED_KEY + id;
    // 1.查询top5的点赞用户 zrange key 0 4
    Set<String> top5 = stringRedisTemplate.opsForZSet().range(key, 0, 4);
    if (top5 == null || top5.isEmpty()) {
        return Result.ok(Collections.emptyList());
    }
    // 2.解析出其中的用户id
    List<Long> ids = top5.stream().map(Long::valueOf).collect(Collectors.toList());
    String idStr = StrUtil.join(",", ids);
    // 3.根据用户id查询用户 WHERE id IN ( 5 , 1 ) ORDER BY FIELD(id, 5, 1)
    List<UserDTO> userDTOS = userService.query()
            // WHERE id IN ( 5 , 1 ) ORDER BY FIELD(id, 5, 1)
            .in("id", ids).last("ORDER BY FIELD(id," + idStr + ")").list()
            .stream()
            .map(user -> BeanUtil.copyProperties(user, UserDTO.class))
            .collect(Collectors.toList());
    // 4.返回
    return Result.ok(userDTOS);
}

改造

private void isBlogLiked(Blog blog) {
    // 1.获取登录用户，使用原来判断用户，就会出现NPE（空指针）如果登录一个新用户进来在首页就不能查询到探店笔记
    UserDTO user = UserHolder.getUser();
    if (user == null) {
        // 用户未登录，无需查询是否点赞
        return;
    }
    Long userId = user.getId();
    // 2.判断当前登录用户是否已经点赞
    String key = "blog:liked:" + blog.getId();
    Double score = stringRedisTemplate.opsForZSet().score(key, userId.toString());
    blog.setIsLike(score != null);
}

好友关注

关注和取关

需求：基于该表数据结构，实现两个接口：

① 关注和取关接口

② 判断是否关注的接口

关注是User之间的关系，是博主与粉丝的关系，数据库中有一张tb_follow表来标示：

DROP TABLE IF EXISTS `tb_follow`;
CREATE TABLE `tb_follow`
(
    `id`             bigint(20)          NOT NULL AUTO_INCREMENT COMMENT '主键',
    `user_id`        bigint(20) UNSIGNED NOT NULL COMMENT '用户id',
    `follow_user_id` bigint(20) UNSIGNED NOT NULL COMMENT '关联的用户id',
    `create_time`    timestamp           NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB
  CHARACTER SET = utf8mb4
  COLLATE = utf8mb4_general_ci
  ROW_FORMAT = Compact;

控制测实现代码：

// 关注
@PutMapping("/{id}/{isFollow}")
public Result follow(@PathVariable("id") Long followUserId, @PathVariable("isFollow") Boolean isFollow) {
    return followService.follow(followUserId, isFollow);
}
// 取关
@GetMapping("/or/not/{id}")
public Result isFollow(@PathVariable("id") Long followUserId) {
    return followService.isFollow(followUserId);
}

接口代码：

Result follow(Long followUserId, Boolean isFollow);
// 是否关注
Result isFollow(Long followUserId);

接口实现代码

// 关注
@Override
public Result follow(Long followUserId, Boolean isFollow) {
    // 获取登录用户
    Long userId = UserHolder.getUser().getId();
    String key = "follows:" + userId;
    // 1.判断到底是关注还是取关
    if (isFollow) {
        // 2.关注，新增数据
        Follow follow = new Follow();
        follow.setUserId(userId);
        follow.setFollowUserId(followUserId);
        boolean isSuccess = save(follow);
        if (isSuccess) {
            // 把关注用户的id，放入redis的set集合 sadd userId followerUserId
            stringRedisTemplate.opsForSet().add(key, followUserId.toString());
        }
    } else {
        // 3.取关，删除 delete from tb_follow where user_id = ? and follow_user_id = ?
        boolean isSuccess = remove(new QueryWrapper<Follow>()
                .eq("user_id", userId).eq("follow_user_id", followUserId));
        if (isSuccess) {
            // 把关注用户的id从Redis集合中移除
            stringRedisTemplate.opsForSet().remove(key, followUserId.toString());
        }
    }
    return Result.ok();
}

// 取关
@Override
public Result isFollow(Long followUserId) {
    // 1.获取登录用户
    Long userId = UserHolder.getUser().getId();
    // 2.查询是否关注 select count(*) from tb_follow where user_id = ? and follow_user_id = ?
    Integer count = query().eq("user_id", userId).eq("follow_user_id", followUserId).count();
    // 3.判断
    return Result.ok(count > 0);
}

共同关注

查看自己和别人是否有关注同一个用户

首先要进入到个人的主页就要的用户控制层和个人主页控制测加入一个接口

UserController

@GetMapping("/{id}")
public Result queryUserById(@PathVariable("id") Long userId){
    // 查询详情
    User user = userService.getById(userId);
    if (user == null) {
        return Result.ok();
    }
    UserDTO userDTO = BeanUtil.copyProperties(user, UserDTO.class);
    // 返回
    return Result.ok(userDTO);
}

BlogControlller

 @GetMapping("/of/user")
    public Result queryBlogByUserId(
            @RequestParam(value = "current", defaultValue = "1") Integer current,
            @RequestParam("id") Long id) {
        // 根据用户查询
        Page<Blog> page = blogService.query()
                .eq("user_id", id).page(new Page<>(current, SystemConstants.MAX_PAGE_SIZE));
        // 获取当前页数据
        List<Blog> records = page.getRecords();
        return Result.ok(records);
    }

共同关注控制层代码

@GetMapping("/common/{id}")
public Result followCommons(@PathVariable("id") Long id){
    return followService.followCommons(id);
}

共同关注接口代码

Result followCommons(Long id);

共同关注实现接口代码

@Override
public Result followCommons(Long id) {
    // 1.获取当前用户
    Long userId = UserHolder.getUser().getId();
    String key = "follows:" + userId; // 你自己
    // 2.求交集
    String key2 = "follows:" + id; // 你要看的用户
    Set<String> intersect = stringRedisTemplate.opsForSet().intersect(key, key2); // 你和别人的交集
    if (intersect == null || intersect.isEmpty()) {
        // 无交集
        return Result.ok(Collections.emptyList());
    }
    // 3.解析id集合
    List<Long> ids = intersect.stream().map(Long::valueOf).collect(Collectors.toList());
    // 4.查询用户
    List<UserDTO> users = userService.listByIds(ids)
            .stream()
            .map(user -> BeanUtil.copyProperties(user, UserDTO.class))
            .collect(Collectors.toList());
    return Result.ok(users);
}

共同推送

关注推送也叫做Feed流，直译为投喂。为用户持续的提供“沉浸式”的体验，通过无限下拉刷新获取新的信息。

Feed流的模式

Feed流产品有两种常见模式：

Timeline：不做内容筛选，简单的按照内容发布时间排序，常用于好友或关注。例如朋友圈
- 优点：信息全面，不会有缺失。并且实现也相对简单
- 缺点：信息噪音较多，用户不一定感兴趣，内容获取效率低
智能排序：利用智能算法屏蔽掉违规的、用户不感兴趣的内容。推送用户感兴趣信息来吸引用户
- 优点：投喂用户感兴趣信息，用户粘度很高，容易沉迷
- 缺点：如果算法不精准，可能起到反作用

本例中的个人页面，是基于关注的好友来做Feed流，因此采用Timeline的模式。该模式的实现方案有三种：

拉模式：读扩散
1. 首先其他的用户会进行发送邮箱，发送的越来越多
2. 关注他们的用户就会接受到这个邮箱信息，收到之后会进行一次排序
优点：
- 节省内存：只保存在发件人的邮箱里面，收件人里面的邮箱是不会保存有邮箱信息的
缺点：
- 每次读取都要重新去拉取发件人的邮箱信息，然后在进行排序，耗时较高
推模式：写扩散

每次发送邮箱，每个粉丝都能接受到

优点：
- 关注的人都能收到一份信息，在用户的邮箱里面再进行一次排序，节省了很大的时间
缺点：
- 内存占用比较多，每一个消息都会保存一份
推拉结合：读写混合，兼具推和拉两种模式的优点

推：
- 比如一些普通粉丝，很少的上线，就使用推模式，先将消息存放到发件箱，等他上线再将最新的消息推送给他
拉：
- 比如活跃粉丝，经常的上线观看，就是用拉模式，将消息及时的推送给他

三种模式的对比

	拉模式	推模式	推拉结合
写比例	低	高	中
读比例	高	低	中
用户读取延迟	高	低	低
实现难度	复杂	简单	很复杂
使用场景	很少使用	用户量少（千万以下）、没有大V	过千万的用户量，有大V

本例使用的是推模式：用户量较少，延迟低

基于推模式实现关注推送功能

① 修改新增探店笔记的业务，在保存blog到数据库的同时，推送到粉丝的收件箱

② 收件箱满足可以根据时间戳排序，必须用Redis的数据结构实现

③ 查询收件箱数据时，可以实现分页查询

Feed流中的数据会不断更新，所以数据的角标也在变化，因此不能采用传统的分页模式。

会出现重复读取的现象

所以采用Feed流的滚动分页

使用一个lastId 记录每次查询的最小的值，在下一次查询时就从上一次的最小值开始，也就是这次的最大的值开始

综合来看，List是按照角标进行分页查询的，会出现重复读取，SortedSet结构比较适合作为这些排名榜

实现发送探店笔记给粉丝

@Override
public Result saveBlog(Blog blog) {
    // 1.获取登录用户
    UserDTO user = UserHolder.getUser();
    blog.setUserId(user.getId());
    // 2.保存探店笔记
    boolean isSuccess = save(blog);
    if (!isSuccess) {
        return Result.fail("新增笔记失败!");
    }
    // 3.查询笔记作者的所有粉丝 select * from tb_follow where follow_user_id = ? 被关注的人的id等于登录用户的id，就能看到自己的粉丝
    List<Follow> follows = followService.query().eq("follow_user_id", user.getId()).list();
    // 4.推送笔记id给所有粉丝
    for (Follow follow : follows) {
        // 4.1.获取粉丝id
        Long userId = follow.getUserId();
        // 4.2.推送给粉丝
        String key = FEED_KEY + userId;
        stringRedisTemplate.opsForZSet().add(key, blog.getId().toString(), System.currentTimeMillis());
    }
    // 5.返回id
    return Result.ok(blog.getId());
}

实现关注推送页面的分页查询

需求：在个人主页的“关注”卡片中，查询并展示推送的Blog信息：

采用feed流的滚动分页查询，其中在ZREVRANGBYSCORE的参数说明：

max：当前时间戳，上一次的最小时间戳
min：0，最小的分数值
offset：0，不固定的，如果是第一次则为0，不需要进行偏移，如果有n个分数值相同的则偏移n个（就写n个）
pageSize：3，每一页多少条

实现如下：

/**
 * @author Shier
 * 返回值参数
 */
@Data
public class ScrollResult {
    private List<?> list;
    private Long minTime;
    private Integer offset;
}

控制层定义接口

/**
     * 关注推送页面的分页查询
     * @param max 最大的分数值
     * @param offset 偏移量，第一次为默认值0，不需要偏移
     * @return
     */
    @GetMapping("/of/follow")
    public Result queryBlogOfFollow(@RequestParam("lastId") Long max, @RequestParam(value = "offset", defaultValue = "0") Integer offset){
        return blogService.queryBlogOfFollow(max, offset);
    }

接口

Result queryBlogOfFollow(Long max, Integer offset);

实现类

/**
 * 查询收件箱里面的所有笔记，然后进行分页查询
 * @param max
 * @param offset
 * @return
 */
@Override
public Result queryBlogOfFollow(Long max, Integer offset) {
    // 1.获取当前用户
    Long userId = UserHolder.getUser().getId();
    // 2.查询收件箱 ZREVRANGEBYSCORE key Max Min LIMIT offset count
    String key = FEED_KEY + userId;
    Set<ZSetOperations.TypedTuple<String>> typedTuples = stringRedisTemplate.opsForZSet()
            .reverseRangeByScoreWithScores(key, 0, max, offset, 2);
    // 3.非空判断
    if (typedTuples == null || typedTuples.isEmpty()) {
        return Result.ok();
    }
    // 4.解析数据：blogId、minTime（时间戳）、offset
    // 需要指定大小，源码中默认的大小为16
    List<Long> ids = new ArrayList<>(typedTuples.size());
    long minTime = 0;
    // 最少有一个
    int os = 1;
    for (ZSetOperations.TypedTuple<String> tuple : typedTuples) {
        // 4.1.获取id
        ids.add(Long.valueOf(tuple.getValue()));
        // 4.2.获取分数(时间戳）
        long time = tuple.getScore().longValue();
        if (time == minTime) {
            os++;
        } else {
            minTime = time;
            os = 1;
        }
    }
    // 5.根据id查询blog
    String idStr = StrUtil.join(",", ids);
    List<Blog> blogs = query().in("id", ids).last("ORDER BY FIELD(id," + idStr + ")").list();
    for (Blog blog : blogs) {
        // 5.1.查询blog有关的用户
        queryBlogUser(blog);
        // 5.2.查询blog是否被点赞
        isBlogLiked(blog);
    }

    // 6.封装并返回
    ScrollResult r = new ScrollResult();
    r.setList(blogs);
    r.setOffset(os);
    r.setMinTime(minTime);
    return Result.ok(r);
}

附近商户

GEO数据结构

GEO介绍

GEO就是Geolocation的简写形式，代表地理坐标。Redis在3.2版本中加入了对GEO的支持，允许存储地理坐标信息，帮助我们根据经纬度来检索数据。常见的命令有：

GEOADD：添加一个地理空间信息，包含：经度（longitude）、纬度（latitude）、值（member）
GEODIST：计算指定的两个点之间的距离并返回
GEOHASH：将指定member的坐标转为hash字符串形式并返回
GEOPOS：返回指定member的坐标
GEORADIUS：指定圆心、半径，找到该圆内包含的所有member，并按照与圆心之间的距离排序后返回。6.2以后已废弃
GEOSEARCH：在指定范围内搜索member，并按照与指定点之间的距离排序后返回。范围可以是圆形或矩形。6.2.新功能
GEOSEARCHSTORE：与GEOSEARCH功能一致，不过可以把结果存储到一个指定的key。 6.2.新功能

附近商户搜索

按照商户类型做分组，类型相同的商户作为同一组，以typeId为key存入同一个GEO集合中即可

具体的存储方案：

先来一个单元测试

@Test
void loadShopData() {
    // 1.查询店铺信息
    List<Shop> list = shopService.list();
    // 2.把店铺分组，按照typeId分组，typeId一致的放到一个集合
    Map<Long, List<Shop>> map = list.stream().collect(Collectors.groupingBy(Shop::getTypeId));
    // 3.分批完成写入Redis
    for (Map.Entry<Long, List<Shop>> entry : map.entrySet()) {
        // 3.1.获取类型id
        Long typeId = entry.getKey();
        String key = SHOP_GEO_KEY + typeId;
        // 3.2.获取同类型的店铺的集合
        List<Shop> value = entry.getValue();
        List<RedisGeoCommands.GeoLocation<String>> locations = new ArrayList<>(value.size());
        // 3.3.写入redis GEOADD key 经度 纬度 member
        for (Shop shop : value) {
            // stringRedisTemplate.opsForGeo().add(key, new Point(shop.getX(), shop.getY()), shop.getId().toString());
            // 写法2
            locations.add(new RedisGeoCommands.GeoLocation<>(
                    shop.getId().toString(),
                    new Point(shop.getX(), shop.getY())
            ));
        }
        stringRedisTemplate.opsForGeo().add(key, locations);
    }
}

具体的实现：

修改原来的接口

/**
 * 根据商铺类型分页查询商铺信息
 *
 * @param typeId  商铺类型
 * @param current 页码
 * @return 商铺列表
 */
@GetMapping("/of/type")
public Result queryShopByType(
        @RequestParam("typeId") Integer typeId,
        @RequestParam(value = "current", defaultValue = "1") Integer current,
        @RequestParam(value = "x", required = false) Double x,
        @RequestParam(value = "y", required = false) Double y
) {
    return shopService.queryShopByType(typeId, current, x, y);
}

queryShopByType方法：

@Override
public Result queryShopByType(Integer typeId, Integer current, Double x, Double y) {
    // 1.判断是否需要根据坐标查询
    if (x == null || y == null) {
        // 不需要坐标查询，按数据库查询
        Page<Shop> page = query()
                .eq("type_id", typeId)
                .page(new Page<>(current, SystemConstants.DEFAULT_PAGE_SIZE));
        // 返回数据
        return Result.ok(page.getRecords());
    }

    // 2.计算分页参数
    int from = (current - 1) * SystemConstants.DEFAULT_PAGE_SIZE;
    int end = current * SystemConstants.DEFAULT_PAGE_SIZE;

    // 3.查询redis、按照距离排序、分页。结果：shopId、distance
    String key = SHOP_GEO_KEY + typeId;
    // GEOSEARCH key BYLONLAT x y BYRADIUS 10 WITHDISTANCE
    GeoResults<RedisGeoCommands.GeoLocation<String>> results = stringRedisTemplate.opsForGeo()
            .search(
                    key,
                    GeoReference.fromCoordinate(x, y),
                    new Distance(5000),
                    RedisGeoCommands.GeoSearchCommandArgs.newGeoSearchArgs().includeDistance().limit(end)
            );
    // 4.解析出id
    if (results == null) {
        return Result.ok(Collections.emptyList());
    }
    List<GeoResult<RedisGeoCommands.GeoLocation<String>>> list = results.getContent();
    if (list.size() <= from) {
        // 没有下一页了，结束
        return Result.ok(Collections.emptyList());
    }
    // 4.1.截取 from ~ end的部分
    List<Long> ids = new ArrayList<>(list.size());
    Map<String, Distance> distanceMap = new HashMap<>(list.size());
    list.stream().skip(from).forEach(result -> {
        // 4.2.获取店铺id
        String shopIdStr = result.getContent().getName();
        ids.add(Long.valueOf(shopIdStr));
        // 4.3.获取距离
        Distance distance = result.getDistance();
        distanceMap.put(shopIdStr, distance);
    });
    // 5.根据id查询Shop
    String idStr = StrUtil.join(",", ids);
    List<Shop> shops = query().in("id", ids).last("ORDER BY FIELD(id," + idStr + ")").list();
    for (Shop shop : shops) {
        shop.setDistance(distanceMap.get(shop.getId().toString()).getValue());
    }
    // 6.返回
    return Result.ok(shops);
}

用户签到

BitMap用法

Redis中是利用string类型数据结构实现BitMap**，**因此最大上限是512M，转换为bit则是 2³²个bit位。

BitMap的操作命令

SETBIT：向指定位置（offset）存入一个0或1
GETBIT ：获取指定位置（offset）的bit值
BITCOUNT ：统计BitMap中值为1的bit位的数量
BITFIELD ：操作（查询、修改、自增）BitMap中bit数组中的指定位置（offset）的值
BITFIELD_RO ：获取BitMap中bit数组，并以十进制形式返回
BITOP ：将多个BitMap的结果做位运算（与、或、异或）
BITPOS ：查找bit数组中指定范围内第一个0或1出现的位置

设置成功返回0，

查看某一天是否成功签到：1-签到成功，0-签到失败

统计一共签到成功的次数

读取多个bit位，返回十进制

签到功能

需求：实现签到接口，将当前用户当天签到信息保存到Redis中

接口信息定义

@PostMapping("/sign")
public Result sign(){
    return userService.sign();
}

接口的实现如下：

@Override
public Result sign() {
    // 1.获取当前登录用户
    Long userId = UserHolder.getUser().getId();
    // 2.获取日期
    LocalDateTime now = LocalDateTime.now();
    // 3.拼接key
    String keySuffix = now.format(DateTimeFormatter.ofPattern(":yyyyMM"));
    String key = USER_SIGN_KEY + userId + keySuffix;
    // 4.获取今天是本月的第几天
    int dayOfMonth = now.getDayOfMonth();
    // 5.写入Redis SETBIT key offset 1
    stringRedisTemplate.opsForValue().setBit(key, dayOfMonth - 1, true);
    return Result.ok();
}

签到统计

接口实现方法：

@Override
public Result signCount() {
    // 1.获取当前登录用户
    Long userId = UserHolder.getUser().getId();
    // 2.获取日期
    LocalDateTime now = LocalDateTime.now();
    // 3.拼接key
    String keySuffix = now.format(DateTimeFormatter.ofPattern(":yyyyMM"));
    String key = USER_SIGN_KEY + userId + keySuffix;
    // 4.获取今天是本月的第几天
    int dayOfMonth = now.getDayOfMonth();
    // 5.获取本月截止今天为止的所有的签到记录，返回的是一个十进制的数字 BITFIELD sign:5:202203 GET u14 0
    List<Long> result = stringRedisTemplate.opsForValue().bitField(
            key,
            BitFieldSubCommands.create()
                    .get(BitFieldSubCommands.BitFieldType.unsigned(dayOfMonth)).valueAt(0)
    );
    if (result == null || result.isEmpty()) {
        // 没有任何签到结果
        return Result.ok(0);
    }
    Long num = result.get(0);
    if (num == null || num == 0) {
        return Result.ok(0);
    }
    // 6.循环遍历
    int count = 0;
    while (true) {
        // 6.1.让这个数字与1做与运算，得到数字的最后一个bit位  // 判断这个bit位是否为0
        if ((num & 1) == 0) {
            // 如果为0，说明未签到，结束
            break;
        } else {
            // 如果不为0，说明已签到，计数器+1
            count++;
        }
        // 把数字右移一位，抛弃最后一个bit位，继续下一个bit位
        num >>>= 1;
    }
    return Result.ok(count);
}

UV统计

HyperLogLog用法

首先我们搞懂两个概念：

UV：全称Unique Visitor，也叫独立访客量，是指通过互联网访问、浏览这个网页的自然人。1天内同一个用户多次访问该网站，只记录1次。
PV：全称Page View，也叫页面访问量或点击量，用户每访问网站的一个页面，记录1次PV，用户多次打开页面，则记录多次PV。往往用来衡量网站的流量。（会被刷量）

通常结合两个来进行看你的网站的流量情况

UV统计在服务端做会比较麻烦，因为要判断该用户是否已经统计过了，需要将统计过的用户信息保存。但是如果每个访问的用户都保存到Redis中，数据量会非常恐怖。

Hyperloglog(HLL)是从Loglog算法派生的概率算法，用于确定非常大的集合的基数，而不需要存储其所有值。相关算法原理参考

Redis中的HLL是基于string结构实现的，单个HLL的内存永远小于16kb，内存占用低的令人发指！作为代价，其测量结果是概率性的，有小于0.81％的误差。不过对于UV统计来说，这完全可以忽略。

三个命令：

测试一下这些指令：

先添加一些元素，后面查询一下，后面再插入重复的元素，但是都是只有5个，得出，HLL能很好的统计。

实现UV统计

我们直接利用单元测试，向HyperLogLog中添加100万条数据，看看内存占用和统计效果如何：

@Test
void testHyperLogLog() {
    String[] values = new String[1000];
    int j = 0;
    for (int i = 0; i < 1000000; i++) {
        j = i % 1000;
        values[j] = "user_" + i;
        if(j == 999){
            // 发送到Redis
            stringRedisTemplate.opsForHyperLogLog().add("hl2", values);
        }
    }
    // 统计数量
    Long count = stringRedisTemplate.opsForHyperLogLog().size("hl2");
    System.out.println("count = " + count);
}

得出的结论：占用的内存小，误差也不算大，100W有两千多的误差还是可以的了。