分布式锁-Redisson-读写锁

本文详细介绍了读写锁的工作原理及其实现方式。通过具体的代码示例解释了读锁和写锁之间的相互作用,包括读+读、写+读、写+写、读+写等不同场景下锁的行为表现。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

/**
 * 保证一定能读到最新数据,修改期间,写锁是一个排他锁(互斥锁)。读锁是一个共享锁
 * 写锁没释放,读就必须等待
 */
@GetMapping("/read")
@ResponseBody
public String readValue() {

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


@GetMapping("/write")
@ResponseBody
public String writeValue() {

    RReadWriteLock readWriteLock = redisson.getReadWriteLock("rw-lock");
    String s = "";
    RLock rLock = readWriteLock.writeLock();
    try {
        //1、改数据加写锁,读数据加读锁
        rLock.lock();
        TimeUnit.SECONDS.sleep(10);
        s = UUID.randomUUID().toString();
        stringRedisTemplate.opsForValue().set("writeValue", s);
    } catch (InterruptedException e) {
        e.printStackTrace();
    } finally {
        rLock.unlock();
    }
    return s;
}

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

### ZooKeeper 和 Redisson 实现分布式锁的方式 #### ZooKeeper 的实现方式 ZooKeeper 提供了一种可靠的机制来构建分布式应用程序中的协调服务。为了创建一个分布式锁,在 ZooKeeper 中通常会使用临时顺序节点[^1]。 当客户端尝试获取锁时,它会在特定路径下创建一个临时顺序节点。通过检查已有的子节点数量以及当前创建的节点编号,可以判断是否获得了锁。如果获得,则继续执行;如果没有,则监听前驱节点的变化事件并等待释放通知。 这种方式确保了即使某个进程崩溃退出后也不会遗留未清理的数据结构,因为一旦连接断开,对应的临时节点就会自动删除。 ```java InterProcessMutex lock = new InterProcessMutex(client, "/lockpath"); try { lock.acquire(); } finally { lock.release(); } ``` #### Redisson 的实现方式 Redisson 是基于 Redis 构建的一个 Java 库,提供了多种分布式对象和服务的支持,其中包括分布式锁功能。Redisson 使用 Redis 来存储锁的状态信息,并利用 Lua 脚本来保证原子操作完成加解锁过程[^2]。 对于可重入锁而言,每次请求都会增加计数器值直到达到最大限制为止。这使得同一个线程可以在不违反互斥条件的情况下多次获取相同的锁实例而不会发生死锁现象。 另外值得注意的是,由于 Redis 单点故障可能导致数据丢失风险,因此建议配置高可用集群模式以提高系统的稳定性和可靠性。 ```java RLock fairLock = redisson.getFairLock("anyLock"); // 尝试加锁,默认无限期阻塞直至成功 fairLock.lock(); // 解锁 fairLock.unlock(); ``` ### 性能对比分析 - **一致性模型**:ZooKeeper 基于 Paxos 或 ZAB(Zookeeper Atomic Broadcast)协议实现了强一致性的共识算法,适用于对数据一致性有严格要求的应用场景。相比之下,Redis 默认采用最终一致性模型,但在某些情况下也可以提供因果一致性保障。 - **吞吐量与延迟**:一般来说,Redis 在读写性能方面优于 Zookeeper ,特别是在处理大量并发访问时表现出色。然而具体表现取决于实际部署环境下的网络状况等因素影响。 综上所述,选择哪种工具作为分布式锁解决方案应考虑业务需求特点、系统架构设计等多个因素共同决定。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值