Redisson实现锁以及redis缓存一致性问题

目录

 RedissonClient实现最基本的锁

RedissonClient实现读写锁

RedissonClient实现闭锁

RedissonClient信号量

缓存不一致问题解决方案

一、双写模式

二、失效模式

---

 RedissonClient实现最基本的锁

        // 1、获取一把锁，只要锁的名字一样，就是同一把锁
        RLock mylock = redisson.getLock("mylock");

        // 2、获取锁并执行业务
        //mylock.lock(); // 加锁，阻塞式等待，默认加的锁都是30s时间
        // 1) 锁的自动续期，如果业务超长，运行期间自动给锁续上新的30s（看门狗机制），不用担心业务时间长导致锁自动过期被删掉
        // 2) 加锁的业务只要运行完成，就不会给当前锁续期，即使不手动解锁，锁默认30s以后自动删除
        mylock.lock(10, TimeUnit.SECONDS);
        // 上面这个锁时间到了以后，不会自动续费
        // 1、如果我们传递了锁的超时时间，就发送给redis执行脚本，进行占领，默认超时时间就是我们指定的时间
        // 2、如果我们未指定锁的超时时间，就是用30*1000【lockWatchDogTimeout看门狗的默认时间】
        //  只要占领成功，就会启动一个定时任务【重新给锁设置过期时间，新的过期时间就是看门狗的默认时间】，每隔10s都会自动续期
        //  internalLockLeaseTime【看门狗时间】 / 3 == 10s  10s一续期
        try {
            System.out.println("加锁成功，执行业务，" + Thread.currentThread().toString());
        } catch (Exception e) {

        } finally {
            // 无论业务执行的如何都得释放锁
            mylock.unlock();
            System.out.println("释放锁，" + Thread.currentThread().toString());
        }

RedissonClient实现读写锁

    // 保证一定能读到最新数据，修改期间，写锁是一个排他锁（互斥锁）。读锁是一个共享锁
    // 写锁没释放读就必须等待
    // 读 + 读 ： 相当于无锁，并发读，只会在redis中记录好，所有当前的读锁，他们都会同时加锁成功
    // 写 + 读 ： 等待写锁释放
    // 写 + 写 ： 阻塞方式
    // 读 + 写 ： 有读锁，写也需要等待
    //
    @GetMapping("/write")
    @ResponseBody
    public String writeValue() {
        RReadWriteLock lock = redisson.getReadWriteLock("rw-lock");
        String s = "";
        // 写锁
        RLock rLock = lock.writeLock();
        try {
            // 写锁上锁
            rLock.lock();
            System.out.println("写锁加锁成功。。。" + Thread.currentThread().toString());
            s = UUID.randomUUID().toString();
            Thread.sleep(30000);
            redisTemplate.opsForValue().set("writeValue", s);
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            rLock.unlock();
            System.out.println("写锁释放。。。" + Thread.currentThread().toString());
        }
        return s;
    }

    @GetMapping("/read")
    @ResponseBody
    public String readValue() {
        RReadWriteLock lock = redisson.getReadWriteLock("rw-lock");
        String s = "";
        // 写锁
        RLock rLock = lock.readLock();
        try {
            // 写锁上锁
            rLock.lock();
            System.out.println("读锁加锁成功。。。" + Thread.currentThread().toString());
            s = UUID.randomUUID().toString();
            Thread.sleep(30000);
            s = redisTemplate.opsForValue().get("writeValue");
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            rLock.unlock();
            System.out.println("读锁释放。。。" + Thread.currentThread().toString());
        }
        return s;
    }

RedissonClient实现闭锁

    // 等待房间内的5个人离开后闭锁才能成功，否则await一直阻塞
    @GetMapping("/lockDoor")
    @ResponseBody
    public String lockDoor() throws InterruptedException {
        RCountDownLatch lock = redisson.getCountDownLatch("door");
        lock.trySetCount(5);
        lock.await(); // 阻塞等待闭锁完成
        
        return "锁门成功";
    }

    @GetMapping("/leave/{id}")
    @ResponseBody
    public String leave(@PathVariable("id")Long id) throws InterruptedException {
        RCountDownLatch lock = redisson.getCountDownLatch("door");
        lock.countDown();  // 计数-1

        return id + "离开了房间";
    }

RedissonClient信号量

    // 需要先在redis中存储semaphore这个key并设置数量
    // 信号量也可以用作分布式限流
    @GetMapping("/semaphore")
    @ResponseBody
    public String park() throws InterruptedException {
        RSemaphore semaphore = redisson.getSemaphore("semaphore");
        semaphore.acquire(); // 获得信号量，必须获得，否则阻塞
        /*
        boolean b = semaphore.tryAcquire();// 尝试获得，可通过返回值进行一定的操作
        if(b) {
            // ....
        } else {
            // .... return error啥的
        }
        */
        return "获得信号量成功";
    }

    @GetMapping("/go")
    @ResponseBody
    public String go() throws InterruptedException {
        RSemaphore semaphore = redisson.getSemaphore("semaphore");
        semaphore.release();  // 释放信号量
        return "go";
    }

缓存不一致问题解决方案

一、双写模式

在更新数据库后立即更新缓存，但是有漏洞，

由于卡顿等原因，导致写缓存 2 在最前，写缓存 1 在后面就出现了不一致

这是暂时性的脏数据问题，但是在数据稳定，缓存过期以后，又能得到最新的正确数据，即能够保证最终一致性

 

二、失效模式

在更新数据库后将缓存直接删除，简单方便，但是也可能出现漏洞

读缓存线程读取的仍然是旧数据，写进缓存的也是旧的数据 

无论是双写模式还是失效模式，都会导致缓存的不一致问题。即多个实例同时更新会出事。怎么办？

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

总结：

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