【redis】加入缓存引发的一系列问题

怼烎@ 2023-02-13 12:24 18阅读 0赞

如上篇博客展示的，三级分类的数据获取吞吐量明显下降，对于分类这种数据，读多写少，我们考虑加入缓存，这样减少和数据库的IO，提升系统性能，但是随之而来的是另一些问题：  
1、数据库和缓存怎么保证数据一致性  
2、分布式环境下访问同一资源怎么保证数据一致性  
3、缓存失效导致的缓存穿透、缓存雪崩、缓存击穿怎么处理

**穿透：**  
查缓存中没有的数据，不命中（解决：允许将null存入缓存）  
**雪崩：**  
缓存同时过期，大量请求压到数据库（解决：所有存入缓存的数据加过期时间）  
**击穿：**  
高频热点key缓存刚刚过期，百万请求过来查，大量请求压到数据库（解决：加锁，第一个请求获得锁后，查出数据存入缓存，其他请求到缓存查的时候就有数据了）

加锁，加什么锁？本地锁只能锁住当前进程，要想锁多进程必用分布式锁才锁得住。  
**加锁注意问题：**  
1、时序问题：要保证入库和入缓存在同一锁内，防止两次查数据库  
2、死锁问题：设置过期时间，但要保证加锁和设置锁过期时间的原子性，否则未设置过期时间，redis宕机，锁就删不了  
3、锁误删：删锁也要保证原子性，假如设置过期时间10s，A线程业务执行了9.5s，请求redis删锁，在它返回响应前到了过期时间，B线程将锁占用，A执行到对比value发现一致，执行删锁，这时删掉的是B线程的锁，所以使用lua脚本执行删锁，要么执行成功，要么失败。  
lua脚本：

if redis.call(“get”,KEYS[1]) == ARGV[1] then
        return redis.call(“del”,KEYS[1])
    else
        return 0
    end

分布式锁实现要考虑这么多问题，在redis中官方早有推荐**Redisson实现分布式锁**：

//获取锁
    RLock myLock = redissonClient.getLock("myLock");
    //加锁 阻塞式等待（底层：死循环不断尝试获取锁）
    //解决死锁 默认过期时间30s，即使宕机也不会死锁
    //myLock.lock();
    //redisson看门狗 自动续期解决锁误删问题
    //1、锁自动续期 业务超长，到期自动续期30s，不会出现锁自动过期被删问题
    //2、加锁的业务运行完成，不会给当前锁续期，即使不手动解锁，默认在30s后自动删除
    
    //10s自动解锁 自动解锁时间一定要大于业务时间 
    //问题：myLock.lock(10,TimeUnit.SECONDS);不能续期 
    //1、如果传超时时间，会发给redis执行脚本，占锁，默认超时就是我们指定的时间
    //2、如果不传超时时间，使用LockWatchdogTimeout看门狗的默认时间30s
    // 只要占锁成功，就会启动一个定时任务（重新设置超时时间，就是看门狗的时间） 
    // 1/3看门狗的时间，也就是10s以后续期
    //建议以下这种方法 省掉续期操作，手动解锁
    myLock.lock(10,TimeUnit.SECONDS);
    try { 
        System.out.println("加锁成功，执行业务"+Thread.currentThread().getId());
        //Thread.sleep(30000);
    }catch (Exception e){ 
    
    }finally { 
        //释放锁
        System.out.println("释放锁"+Thread.currentThread().getId());
        myLock.unlock();
    }

另外redisson还提供了读写锁：

//保证一定能读到最新数据，修改期间，写锁是一个排他锁，读锁是个共享锁
    //写锁没释放就必需等待
    // 读+读：相当于无锁，并发读只会redis中
    // 写+读：等待写锁释放
    // 写+写：阻塞
    // 读+写：有读锁 写也要等待
    @RequestMapping("/write")
    @ResponseBody
    public String writeValue(){ 
        RReadWriteLock readWriteLock = redissonClient.getReadWriteLock("rw-lock");
        RLock rLock = readWriteLock.writeLock();
    
        String s = "";
        try { 
            rLock.lock();
            System.out.println("写锁加锁成功");
            s = UUID.randomUUID().toString();
            Thread.sleep(30000);
            redisTemplate.opsForValue().set("writeValue",s);
        }catch (Exception e){ 
    
        }finally { 
            rLock.unlock();
            System.out.println("写锁释放");
        }
        return s;
    }
    
    @RequestMapping("/read")
    @ResponseBody
    public String readValue(){ 
        RReadWriteLock readWriteLock = redissonClient.getReadWriteLock("rw-lock");
        RLock rLock = readWriteLock.readLock();
        rLock.lock();
        String s = "";
        try { 
            s = (String) redisTemplate.opsForValue().get("writeValue");
        }catch (Exception e){ 
    
        }finally { 
            rLock.unlock();
            System.out.println("读锁释放");
        }
        return s;
    }

**数据库和缓存一致性问题：**  
无论双写模式还是失效模式都会导致数据不一致的问题，解决方案：  
1、保证缓存数据加过期时间，数据过期下次查询会主动更新（缓存+过期时间可解决大部分业务的需求）  
2、通过加读写锁解决读写并发，前提是读多写少  
3、先删除缓存再更新数据库（这样即使删缓存出错，数据库还未更新，不存在一致性问题）  
4、**高并发读写问题**：先删缓存成功，还未更新数据库，这时又一请求来查redis，为null，去DB将旧数据查出，这时第一个请求更新完DB，两边不一致。  
针对亿级流量读写并发：DB与缓存更新与读取串行化  
相同商品，将请求路由到同一队列，如果队列已有更新操作（删缓存更新DB）和一个读请求（查DB加缓存），其他读请求要夯时（不用入队列），如果没有不需夯时，在外夯200ms，200ms内读到缓存数据了可以返回，如果没有直接到数据库查。

**总结：**  
我们放入的数据不该是实时性，一致性较高的；  
不应该过度设计，增加系统复杂性；  
对实时性，一致性要求高的数据，我们宁可查数据库。