Redisson读写锁

在高并发场景下如果只用一把互斥锁会出现哪些问题?
  • 同一时间只能有一个请求占用,如果是大量的并发上来,性能是会急剧下降的,所有的请求都得加锁比如如果数据没有进行任何修改的话,是不需要加锁的。
  • 如果读数据的请求还没读完,这个时候来了一个写请求,这个时候是不能写数据的,不然数据就不正确了,要等到前面读锁全部释放掉以后,写请求才能执行,所以需要给这个读请求加一个标识(读锁),让写请求知道,这个时候是不能修改数据的,不然数据就不一致了。
  • 如果已经有人在写数据了,再来一个请求写数据,也是不允许的,这样也会导致数据的不一致,所以所有的写请求,都需要加一个写锁,是为了避免同时对共享数据进行写操作。
Redisson给我们提供了读写锁机制,我们可以用读写锁在保证数据并发安全同时优化我们热点key的读写效率
/**
 * 保证一定能读到最新数据,修改期间,写锁是一个排他锁(互斥锁)。读锁是一个共享锁
 * 写锁没释放,读就必须等待
 */
@GetMapping("/readHotKeyValue")
@ResponseBody
public String readHotKeyValue() {

    RReadWriteLock readWriteLock = redisson.getReadWriteLock("rw-lock");
    String s = "";
    RLock rLock = readWriteLock.readLock();
    try {
        rLock.lock();
        s = stringRedisTemplate.opsForValue().get("myhotkey");
    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        rLock.unlock();
    }
    return s;
}


@PostMapping("/writeHotKeyValue")
@ResponseBody
public boolean writeHotKeyValue() {

    RReadWriteLock readWriteLock = redisson.getReadWriteLock("rw-lock");
    boolean result = true;
    String s = "";
    RLock wLock = readWriteLock.writeLock();
    try {
        // 1、改数据加写锁,读数据加读锁
        wLock.lock();
        // 具体业务处理逻辑...
        s = UUID.randomUUID().toString();
        stringRedisTemplate.opsForValue().set("myHotKey", s);
    } catch (InterruptedException e) {
    	result = false;
        e.printStackTrace();
    } finally {
        wLock.unlock();
    }
    return result;
}

  • 读 + 读: 相当于无锁,并发读,只会在redis中记录好,所有当前的读锁,他们都会同时加锁成功
  • 写 + 读: 等待写锁释放
  • 写 + 写: 阻塞方式
  • 读 + 写: 有读锁,写也需要等待
总之:只要有写的存在,都必须等待
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值