Day412.分布式锁redisson与缓存 -谷粒商城

分布式锁redisson与缓存

• 读模式缓存使用流程

• 缓存

本地缓存：和微服务同一个进程。缺点：分布式时本都缓存不能共享

分布式缓存：缓存中间件

---

一、本地缓存

category、brand、product

• 安装docker-redis

https://blog.csdn.net/qq_43284469/article/details/120397138

• product导入依赖

<dependency>
    <groupId>org.springframework.bootgroupId>
    <artifactId>spring-boot-starter-data-redisartifactId>
dependency>

• 配置redis主机地址

spring: 
  redis:
    host: 192.168.109.101
    port: 6379

• 自动注入了RedisTemplate

• 优化菜单获取业务getCatalogJson

@Override
public Map<Long, List<Catelog2Vo>>  getCatelogJson() {
     
    String catelogJson = redisTemplate.opsForValue().get("catelogJson");
    if (StringUtils.isEmpty(catelogJson)){
     
        //缓存中没有
        Map<Long, List<Catelog2Vo>> catelogJsonFromDB = getCatelogJsonFromDB();
        redisTemplate.opsForValue().set("catelogJson",JSON.toJSONString(catelogJsonFromDB));
        return catelogJsonFromDB;
    }

    //因为转化的对象是复杂对象，所以通过TypeReference
    Map<Long, List<Catelog2Vo>> catelogJsonFromDB = JSON.parseObject(catelogJson,new TypeReference<Map<Long, List<Catelog2Vo>>>(){
     });
    return catelogJsonFromDB;
}




//从数据库查询数据
public Map<Long, List<Catelog2Vo>>  getCatelogJsonFromDB() {
     
    //将数据库的多次交互，转为一次，一次性查询所有数据
    List<CategoryEntity> allList = baseMapper.selectList(null);
    //查出所有分类
    List<CategoryEntity> level1Categorys = getParent_cid(allList,0L);
    //分装数据
    Map<Long, List<Catelog2Vo>> resultMap = level1Categorys.stream().collect(Collectors.toMap(CategoryEntity::getCatId, v -> {
     
        //每一个的一级分类，查到这个一级分类的二级分类
        List<CategoryEntity> list = getParent_cid(allList,v.getCatId());
        List<Catelog2Vo> catelog2VoList = null;
        if (!StringUtils.isEmpty(list)) {
     
            catelog2VoList = list.stream().map(item -> {
     
                Catelog2Vo catelog2Vo = new Catelog2Vo(v.getCatId().toString(), null, item.getCatId().toString(), item.getName());
                //封装二级分类的三级分类
                List<CategoryEntity> entityList = getParent_cid(allList,item.getCatId());
                if (!StringUtils.isEmpty(entityList)){
     
                    List<Catelog2Vo.Catelog3Vo> catelog3Vos = entityList.stream().map(m -> {
     
                        Catelog2Vo.Catelog3Vo catelog3Vo = new Catelog2Vo.Catelog3Vo(item.getCatId().toString(),m.getCatId().toString(),m.getName());
                        return catelog3Vo;
                    }).collect(Collectors.toList());
                    catelog2Vo.setCatalog3List(catelog3Vos);
                }
                return catelog2Vo;
            }).collect(Collectors.toList());
            return catelog2VoList;
        }
        return catelog2VoList;
    }));
    return resultMap;
}

private List<CategoryEntity> getParent_cid(List<CategoryEntity> allList,Long parent_cid) {
     
    List<CategoryEntity> collect = allList.stream().filter(item -> {
     
        return item.getParentCid().equals(parent_cid);
    }).collect(Collectors.toList());
    return collect;
    //        return baseMapper.selectList(new QueryWrapper().eq("parent_cid", v.getCatId()));
}

• lettuce堆外内存溢出bug

  当进行压力测试时后期后出现堆外内存溢出OutOfDirectMemoryError

  • 产生原因：

    • 1)、springboot2.0以后默认使用lettuce作为操作redis的客户端，它使用netty进行
      网络通信
    • 2)、lettuce的bug导致netty堆外内存溢出。netty如果没有指定堆外内存，默认使
      用Xms的值，可以使用-Dio.netty.maxDirectMemory进行设置

  • 解决方案

    由于是lettuce的bug造成，不要直接使用-Dio.netty.maxDirectMemory 去调大虚拟机堆外内存，治标不治本。

    • 1)、升级lettuce客户端。但是没有解决的
    • 2)、切换使用jedis

    <dependency>
        <groupId>org.springframework.bootgroupId>
        <artifactId>spring-boot-starter-data-redisartifactId>
        <exclusions>
            <exclusion>
                <groupId>io.lettucegroupId>
                <artifactId>lettuce-coreartifactId>
            exclusion>
        exclusions>
    dependency>
    <dependency>
        <groupId>redis.clientsgroupId>
        <artifactId>jedisartifactId>
    dependency>
    

    lettuce和jedis是操作redis的底层客户端，RedisTemplate是再次封装

• 缓存失效

  • 缓存穿透【不存在的数据】

    • 缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id 为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导 致数据库压力过大。

    • 解决：

      • 缓存空对象、布隆过滤器、mvc拦截器

  • 缓存雪崩【缓存在某一时刻 同时失效】

    • 缓存雪崩是指在我们设置缓存时key采用了相同的过期时间，导致缓存在某一时刻 同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

    • 解决方案

      • 规避雪崩：缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
        如果缓存数据库是分布式部署，将热点数据均匀分布在不同缓存数据库中。
        设置热点数据永远不过期。
        出现雪崩：降级 熔断
        事前：尽量保证整个 redis 集群的高可用性，发现机器宕机尽快补上。选择合适的内存淘汰策略。
        事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL崩掉
        事后：利用 redis 持久化机制保存的数据尽快恢复缓存

  • 缓存击穿【并发查同一条数据】

    • 缓存击穿 指 并发查同一条数据。缓存击穿是指缓存中没有但数据库中有的数据 （一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据， 又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力 缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

    • 解决方案：

      • 设置热点数据永远不过期。
        加互斥锁：业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效
        的时候（判断拿出来的值为空），不是立即去load db去数据库加载，而是先使用
        缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache
        的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设
        缓存；否则，就重试整个get缓存的方法。

• 缓存击穿:加锁

  • 不好的方法是synchronized(this)，肯定不能这么写 ，不具体写了 锁时序问题：之前的逻辑是查缓存没有，然后取竞争锁查s数据库，这样就造成多 次查数据库。

  • 解决方法：

    • 竞争到锁后，再次确认缓存中没有，再去查数据库。

    @Override
    public Map<Long, List<Catelog2Vo>> getCatelogJson() {
             
        String catelogJson = redisTemplate.opsForValue().get("catelogJson");
        //缓存中没有
        if (StringUtils.isEmpty(catelogJson)) {
             
            //获取数据返回
            Map<Long, List<Catelog2Vo>> catelogJsonFromDB = getCatelogJsonFromDB();
            return catelogJsonFromDB;
        }
    
        //因为转化的对象是复杂对象，所以通过TypeReference
        Map<Long, List<Catelog2Vo>> catelogJsonFromDB = JSON.parseObject(catelogJson, new TypeReference<Map<Long, List<Catelog2Vo>>>() {
             
        });
        return catelogJsonFromDB;
    }
    
    
    //从数据库查询数据
    public Map<Long, List<Catelog2Vo>> getCatelogJsonFromDB() {
             
        synchronized (this) {
             
            //判断缓存是否已经有数据，防止之前的线程已经放好数据
            String catelogJson = redisTemplate.opsForValue().get("catelogJsonFromDB");
            if (!StringUtils.isEmpty(catelogJson)) {
             
                //因为转化的对象是复杂对象，所以通过TypeReference
                Map<Long, List<Catelog2Vo>> resultMap = JSON.parseObject(catelogJson, new TypeReference<Map<Long, List<Catelog2Vo>>>() {
             
                });
                return resultMap;
            }
    
    
            //将数据库的多次交互，转为一次，一次性查询所有数据
            List<CategoryEntity> allList = baseMapper.selectList(null);
            //查出所有分类
            List<CategoryEntity> level1Categorys = getParent_cid(allList, 0L);
            //分装数据
            Map<Long, List<Catelog2Vo>> resultMap = level1Categorys.stream().collect(Collectors.toMap(CategoryEntity::getCatId, v -> {
             
                //每一个的一级分类，查到这个一级分类的二级分类
                List<CategoryEntity> list = getParent_cid(allList, v.getCatId());
                List<Catelog2Vo> catelog2VoList = null;
                if (!StringUtils.isEmpty(list)) {
             
                    catelog2VoList = list.stream().map(item -> {
             
                        Catelog2Vo catelog2Vo = new Catelog2Vo(v.getCatId().toString(), null, item.getCatId().toString(), item.getName());
                        //封装二级分类的三级分类
                        List<CategoryEntity> entityList = getParent_cid(allList, item.getCatId());
                        if (!StringUtils.isEmpty(entityList)) {
             
                            List<Catelog2Vo.Catelog3Vo> catelog3Vos = entityList.stream().map(m -> {
             
                                Catelog2Vo.Catelog3Vo catelog3Vo = new Catelog2Vo.Catelog3Vo(item.getCatId().toString(), m.getCatId().toString(), m.getName());
                                return catelog3Vo;
                            }).collect(Collectors.toList());
                            catelog2Vo.setCatalog3List(catelog3Vos);
                        }
                        return catelog2Vo;
                    }).collect(Collectors.toList());
                    return catelog2VoList;
                }
                return catelog2VoList;
            }));
            
            
    
            //放入缓存
            redisTemplate.opsForValue().set("catelogJson", JSON.toJSONString(resultMap),1L, TimeUnit.DAYS);
    
            return resultMap;
        }
    }
    
    
    
    private List<CategoryEntity> getParent_cid(List<CategoryEntity> allList, Long parent_cid) {
             
        List<CategoryEntity> collect = allList.stream().filter(item -> {
             
            return item.getParentCid().equals(parent_cid);
        }).collect(Collectors.toList());
        return collect;
        //        return baseMapper.selectList(new QueryWrapper().eq("parent_cid", v.getCatId()));
    }
    

加锁时序图

保证【确认缓存】、【查数据结果】、【放入缓存】是一个原子操作

上面的本地锁只能锁住当前进程，在分布式的情况下无法保证锁住整个集群服务

---

二、分布式缓存

• 本地缓存问题

每个微服务都要有缓存服务、数据更新时只更新自己的缓存，造 成缓存数据不一致

• 解决方案

分布式缓存，微服务共用 缓存中间件

• 分布式锁

分布式项目时，但本地锁只能锁住当前服务，需要分布式锁

• redis分布式锁的原理

setnx，同一时刻只能设置成功一个 前提，锁的key是一定的，value可以变，

没获取到锁阻塞或者sleep一会

设置好了锁，万一服务出现宕机，没有执行删除锁逻辑，这就造成了死锁

• 解决

  • 设置过期时间
    • 业务还没执行完锁就过期了，别人拿到锁，自己执行完去删了别人的锁
  • 锁续期（redisson有看门狗）
    • 删锁的时候明确是自己的锁。如uuid 判断uuid对了，但是将要删除的时候锁过期了，别人设置了新值，那删除了别人 的锁
  • 删除锁必须保证原子性（保证判断和删锁是原子的）
    • 使用redis+Lua脚本 完成，脚本是原子的

• 最终版代码—redis分布式锁

//从数据库查询数据【Redis分布式锁】
public Map<Long, List<Catelog2Vo>> getCatelogJsonFromDBWithRedisLock() {
     
    String uuid = UUID.randomUUID().toString();
    //设置redis分布式锁，30s自动删除锁
    Boolean isLock = redisTemplate.opsForValue().setIfAbsent("lock", uuid,300L,TimeUnit.SECONDS);
    if (isLock){
     
        //抢锁成功。。。执行业务
        Map<Long, List<Catelog2Vo>> resultMap = null;
        try {
     
            resultMap = getLongListMap();
        }finally {
     
            //lua脚本解锁：让获取数据+对比数据成为原子操作
            String script = "if redis.call(\"get\",KEYS[1]) == ARGV[1] then\n" +
                "    return redis.call(\"del\",KEYS[1])\n" +
                "else\n" +
                "    return 0\n" +
                "end";
            Long lock = redisTemplate.execute(new DefaultRedisScript<Long>(script, Long.class),Arrays.asList("lock"),uuid);
        }
        return resultMap;

    }else {
     
        //抢锁失败。。。重试
        try {
     
            Thread.sleep(200);
        } catch (InterruptedException e) {
     
            e.printStackTrace();
        }
        // 睡眠0.2s后，重新调用 //自旋
        return getCatelogJsonFromDBWithRedisLock();
    }
}

• 上面的lua脚本写法每次用分布式锁时比较麻烦，我们可以采用redisson现有框架

---

三、Redisson

Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务。其中包括(BitSet, Set, Multimap, SortedSet, Map, List, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, Bloom filter, Remote service, Spring cache, Executor service, Live Object service, Scheduler service) Redisson提供了使用Redis的最简单和最便捷的方法。Redisson的宗旨是促进使用者对Redis的关注分离（Separation of Concern），从而让使用者能够将精力更集中地放在处理业务逻辑上。

https://redis.io/topics/distlock

• Redisson

https://github.com/redisson/redisson

1、环境搭建

<dependency>
    <groupId>org.redissongroupId>
    <artifactId>redissonartifactId>
    <version>3.13.4version>
dependency>

这个用作连续，后面可以使用redisson-spring-boot-starter

• 开启配置

https://github.com/redisson/redisson/wiki/14.-%E7%AC%AC%E4%B8%89%E6%96%B9%E6%A1%86%E6%9E%B6%E6%95%B4%E5%90%88

@Configuration
public class RedissonConfig {
     

    @Bean(destroyMethod = "shutdown")
    public RedissonClient redissonClient(){
     
        Config config = new Config();
        config.setTransportMode(TransportMode.EPOLL);
        config.useClusterServers()
                //可以用"rediss://"来启用SSL连接
                .addNodeAddress("redis://192.168.109.101:6379");
        return Redisson.create(config);
    }
   
}

---

2、可重入锁（Reentrant Lock）

• 分布式锁

github.com/redisson/redisson/wiki/8.-分布式锁和同步器

A调用B。AB都需要同一锁，此时可重入锁就可以重入，A就可以调用B。不可重入锁时，A调用B将死锁

// 参数为锁名字
RLock lock = redissonClient.getLock("CatalogJson-Lock");//该锁实现了JUC.locks.lock接口
lock.lock();//阻塞等待
// 解锁放到finally // 如果这里宕机：有看门狗，不用担心
lock.unlock();

基于Redis的Redisson分布式可重入锁RLock Java对象实现了java.util.concurrent.locks.Lock接口。同时还提供了异步（Async）、反射式（Reactive）和RxJava2标准的接口。

• 锁的续期

如果负责储存这个分布式锁的Redisson节点宕机以后，而且这个锁正好处于锁住的状态时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。默认情况下，看门狗的检查锁的超时时间是30秒（每到20s就会自动续借成30s，是1/3的关系），也可以通过修改
Config.lockWatchdogTimeout来另行指定。

// 加锁以后10秒钟自动解锁，看门狗不续命
// 无需调用unlock方法手动解锁
lock.lock(10, TimeUnit.SECONDS);//自动解锁时间一定要大于业务执行时间

// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁
boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS);
if (res) {
     
    try {
     
        ...
    } finally {
     
        lock.unlock();
    }
}

• 如果传递了锁的超时时间，就执行脚本，进行占锁;

• 如果没传递锁时间，使用看门狗的时间，占锁。如果返回占锁成功future，调用future.onComplete();

没异常的话调用scheduleExpirationRenewal(threadId);

重新设置过期时间，定时任务;

看门狗的原理是定时任务：重新给锁设置过期时间，新的过期时间就是看门狗的默认时间;

锁时间/3是定时任务周期;

• Redisson同时还为分布式锁提供了异步执行的相关方法

RLock lock = redisson.getLock("anyLock");
lock.lockAsync();
lock.lockAsync(10, TimeUnit.SECONDS);
Future<Boolean> res = lock.tryLockAsync(100, 10, TimeUnit.SECONDS);

RLock对象完全符合Java的Lock规范。也就是说只有拥有锁的进程才能解锁，其他进程解锁则会抛出IllegalMonitorStateException错误。但是如果遇到需要其他进程也能解锁的情况，请使用分布式信号量Semaphore 对象.

//Redisson分布式锁
public Map<Long, List<Catelog2Vo>> getCatelogJsonFromDBWithRedissonLock() {
     
    RLock lock = redissonClient.getLock("catelog-lock");
    lock.lock();
    //抢锁成功。。。执行业务
    Map<Long, List<Catelog2Vo>> resultMap = null;
    try {
     
        Thread.sleep(30000);
        resultMap = getLongListMap();
    } finally {
     
        lock.unlock();
        return resultMap;
    }
}

---

3、读写锁（ReadWriteLock）

基于Redis的Redisson分布式可重入读写锁RReadWriteLock Java对象实现了java.util.concurrent.locks.ReadWriteLock接口。其中读锁和写锁都继承了RLock 接口。

分布式可重入读写锁允许同时有多个读锁和一个写锁处于加锁状态。

读读共享 读写/写写 都是互斥

RReadWriteLock rwlock = redisson.getReadWriteLock("anyRWLock");
// 最常见的使用方法
rwlock.readLock().lock();
// 或
rwlock.writeLock().lock();

// 10秒钟以后自动解锁
// 无需调用unlock方法手动解锁
rwlock.readLock().lock(10, TimeUnit.SECONDS);
// 或
rwlock.writeLock().lock(10, TimeUnit.SECONDS);

// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁
boolean res = rwlock.readLock().tryLock(100, 10, TimeUnit.SECONDS);
// 或
boolean res = rwlock.writeLock().tryLock(100, 10, TimeUnit.SECONDS);
//...
lock.unlock();

• 上锁时在redis的状态

HashWrite-Lock

key:mode value:read

key:sasdsdffsdfsdf… value:1=

---

4、信号量（Semaphore）

信号量为存储在redis中的一个数字，当这个数字大于0时，即可以调用acquire()方法增加数量，也可以调用release()方法减少数量，但是当调用release()之后小于0的话方法就会阻塞，直到数字大于0

基于Redis的Redisson的分布式信号量（Semaphore）Java对象RSemaphore采用了与java.util.concurrent.Semaphore相似的接口和用法。同时还提供了异步（Async）、反射式（Reactive）和RxJava2标准的接口。

可用于分布式限流【通过tryAcquire()】

RSemaphore semaphore = redisson.getSemaphore("semaphore");
semaphore.acquire();
//或
semaphore.acquireAsync();
semaphore.acquire(23);
semaphore.tryAcquire();
//或
semaphore.tryAcquireAsync();
semaphore.tryAcquire(23, TimeUnit.SECONDS);
//或
semaphore.tryAcquireAsync(23, TimeUnit.SECONDS);
semaphore.release(10);
semaphore.release();
//或
semaphore.releaseAsync();

@GetMapping("/park")
@ResponseBody
public String park() {
     
    RSemaphore park = redissonClient.getSemaphore("park");
    try {
     
        park.acquire(2);
    } catch (InterruptedException e) {
     
        e.printStackTrace();
    }
    return "停进2";
}

@GetMapping("/go")
@ResponseBody
public String go() {
     
    RSemaphore park = redissonClient.getSemaphore("park");
    park.release(2);
    return "开走2";
}

---

5、闭锁（CountDownLatch）

基于Redisson的Redisson分布式闭锁（CountDownLatch）Java对象RCountDownLatch采用了与java.util.concurrent.CountDownLatch相似的接口和用法。

以下代码只有offLatch()被调用5次后 setLatch()才能继续执行

RCountDownLatch latch = redisson.getCountDownLatch("anyCountDownLatch");
latch.trySetCount(1);//设置等待闭锁完成数
latch.await();//等待完成

// 在其他线程或其他JVM里
RCountDownLatch latch = redisson.getCountDownLatch("anyCountDownLatch");
latch.countDown();//计数减1

---

6、缓存和数据库一致性

• 双写模式：写数据库后，写缓存

  • 问题：
    • 并发时，2写进入，写完DB后都写缓存。有暂时的脏数据

• 失效模式：写完数据库后，删缓存

  • 问题：

    • 还没存入数据库呢，线程2又读到旧的DB了

  • 解决：缓存设置过期时间，定期更新

  • 解决：写数据写时，加分布式的读写锁。

  • 解决方案：

    如果是用户纬度数据（订单数据、用户数据），这种并发几率非常小，不用考虑这个问题，缓存数据加上过期时间，每隔一段时间触发读的主动更新即可
    如果是菜单，商品介绍等基础数据，也可以去使用canal订阅binlog的方式
    缓存数据+过期时间也足够解决大部分业务对于缓存的要求。
    通过加锁保证并发读写，写写的时候按顺序排好队。读读无所谓。所以适合使用读写锁。（业务不关心脏数据，允许临时脏数据可忽略）；

• 总结

  • 过期时间
  • 读写锁

我们能放入缓存的数据本就不应该是实时性、一致性要求超高的。所以缓存数据的时候加上过期时间，保证每天拿到当前最新数据即可。 我们不应该过度设计，增加系统的复杂性 遇到实时性、一致性要求高的数据，就应该查数据库，即使慢点。

---