Redis04-分布式锁

Elaine202391

已于 2023-11-13 12:12:08 修改

阅读量471

点赞数 6

分类专栏：面试攻略文章标签：分布式

于 2023-11-12 17:21:49 首次发布

本文链接：https://blog.csdn.net/Elaine2391/article/details/134363054

版权

面试攻略专栏收录该内容

6 篇文章 0 订阅

订阅专栏

Redis实现分布式锁

在单节点的服务器中，java中的synchronized机制是处于JVM层面的，只能保证线程之间的同步。而实际的服务部署中，我们通常会使用多节点的集群部署方式，而要保证多个节点中的不同进程对数据的同步操作，就需要使用分布式锁。

使用分布式锁的主要目的是在分布式环境中确保多个节点之间的协同操作，避免由于并发访问而导致的数据不一致、竞态条件等问题。以下是使用分布式锁的一些常见原因：

避免并发问题： 在分布式系统中，多个节点可能同时对共享资源进行访问。使用分布式锁可以确保对关键资源的访问在同一时刻只有一个节点拥有，避免并发问题，如数据不一致、丢失更新等。
保护共享资源： 分布式系统中的共享资源，例如数据库、缓存、文件等，可能同时被多个节点访问。通过使用分布式锁，可以保护这些共享资源，确保在任何时刻只有一个节点能够修改它们。
防止死锁： 在分布式系统中，由于网络分区、节点故障等原因，可能发生死锁。通过使用分布式锁，可以避免因为多节点间的协同操作导致的死锁问题。
控制访问顺序： 在某些场景下，需要对共享资源的访问进行有序控制，确保一些操作的执行顺序。分布式锁可以用于实现对资源的顺序访问。
实现分布式协调： 分布式锁是实现分布式协调和同步的一种重要机制。例如，在分布式任务调度、分布式事务等场景中，分布式锁可以用于协调不同节点的操作。
防止重复执行： 在一些需要幂等性操作的场景下，分布式锁可以用于防止同一操作被重复执行。
避免“多写”问题： 当多个节点同时写入同一数据时，可能导致“多写”问题，即最后写入的值覆盖了之前的写入。分布式锁可以用于保护写入操作，确保只有一个节点能够写入。

分布式锁的工作流程

Redis实现分布式锁

Redis实现分布式锁主要利用的是Redis的setnx命令。setnx是Set if no exists的简写。

CenOs7:0>setnx lock 1 # 首次设置lock值1
"1"  # 设置成功返回1
CenOs7:0>setnx lock 1 # lock已存在，给lock赋值
"0"  # 设置失败返回0，不做任何操作
CenOs7:0>get lock # 获取lock的值
"1"  # lock值为1
CenOs7:0>del lock # 删除lock，释放锁
"1"  # 删除成功，返回1
CenOs7:0>get lock # 获取lock的值
null # lock为空
CenOs7:0>setnx lock 1 # 设置lock值为1
"1"  # 设置成功

需要注意的是，setnx的方式是不支持重入锁的。而且锁的持有时间很难控制。单纯地依赖expire设置过期时间是不现实的。

Redission的watch dog

Redission引入了“看门狗”的机制，目的是处理锁的续期问题。

代码示例：

import org.redisson.Redisson;
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;

import java.util.concurrent.TimeUnit;

public class RedissonWatchdogExample {

    public static void main(String[] args) throws InterruptedException {
        // 创建 Redisson 客户端
        Config config = new Config();
        config.useSingleServer().setAddress("redis://127.0.0.1:6379");
        RedissonClient redisson = Redisson.create(config);

        // 获取分布式锁
        RLock lock = redisson.getLock("myLock");

        try {
            // 尝试获取锁并设置锁的过期时间为10秒
            // boolean isLocked = lock.tryLock(10, 30, TimeUnit.SECONDS);
            // 如果设置了第二个参数[锁的持续时间]就默认不使用watchdog
            // redission中的lock是依赖了底层lua脚本的原子性实现的
            boolean isLocked = lock.tryLock(10, TimeUnit.SECONDS);

            if (isLocked) {
                // 获取锁成功，执行业务逻辑
                System.out.println("Lock acquired. Executing business logic...");

                // 模拟业务逻辑执行时间
                Thread.sleep(5000);

                // 业务逻辑执行完毕，不需要手动释放锁，Watchdog会自动续期或者释放锁

            } else {
                System.out.println("Failed to acquire the lock within the specified time");
            }

        } finally {
            // 关闭 Redisson 客户端
            redisson.shutdown();
        }
    }
}

创建了一个名为"myLock"的分布式锁，并使用tryLock方法尝试获取锁，设置锁的过期时间为10秒。在获取锁成功后，执行了一段模拟的业务逻辑，并且无需手动释放锁，因为Watchdog会在锁过期时自动续期或释放锁。

Redission实现可重入锁

Redission通过Hash结构实现重入锁的，key对应的是lock，value存放的是线程信息。

需要注意的是，Redisson Watchdog是默认开启的，你不需要额外的配置。在正式的生产环境中，建议你根据实际需求进行更详细的配置，比如设置Watchdog的检查间隔、锁的失效时间等参数。

红锁（RedLock）

Redis集群是主从复制结构，Master负责写，Slave负责读。setnx是在Master实例上进行加锁。

Java应用通过setnx在Master节点获取锁。
Master节点异常，Redis通过哨兵机制选举出新的Master。
Java应用通过setnx在新的Master节点获取锁。
此时集群中存在两把锁，违背了锁的互斥性。

针对这种情况，Redis提供了RedLock，它的主要机制是在(n/2+1)个节点实例上同时创建锁。

RedLock解决了锁的互斥性问题，同时缺点也很明显：实现复杂，性能差，同时运维繁琐。针对分布式中的CAP现象，不同的业务应该选择对应的方案：

AP思想(高可用性+分区容错)：使用Redis实现分布式锁
CP思想(强一致性+分区容错)：使用Zookeeper实现分布式锁

Redis分布式锁的合理应用

Redis分布式锁是在多个节点之间实现互斥访问共享资源的一种机制。它可以应用于各种场景，以下是一些合理的应用场景：

分布式任务调度： 当有多个节点需要执行定时任务或者周期性任务时，可以使用分布式锁确保同一时刻只有一个节点在执行任务，避免重复执行或者竞态条件。
分布式缓存更新： 当多个节点需要同时更新某个缓存或者共享的数据时，可以使用分布式锁确保只有一个节点能够进行更新操作，防止并发问题。
分布式事务： 在分布式事务场景下，可能需要对一些关键资源进行加锁，以确保在事务执行期间，其他事务不会修改这些资源，从而保证事务的隔离性。
防止重复操作： 在一些场景下，可能需要防止某个操作被重复执行。通过使用分布式锁，可以确保同一时刻只有一个节点能够执行这个操作，防止重复操作。
分布式限流： 在某些情况下，需要对请求进行限流，确保系统不被过度请求。通过使用分布式锁，可以控制某个时间窗口内只有一个节点能够处理请求，实现简单的限流效果。
分布式协同： 当多个节点需要协同工作时，可以使用分布式锁确保各个节点之间的操作按照规定的顺序进行，防止不一致或混乱的情况发生。
分布式任务队列： 在分布式环境中，多个节点可能需要消费同一个任务队列。通过使用分布式锁，可以确保只有一个节点能够成功获取并消费队列中的任务，避免重复消费。
资源竞争： 当多个节点需要竞争某个资源时，可以使用分布式锁来进行竞争，确保只有一个节点能够成功占用资源，如分布式锁用于实现分布式秒杀场景。