分布式锁理解

news2024/9/20 22:45:16

介绍分布式锁，我觉得从项目的背景入手把

在伙伴匹配系统中，我创建了一个定时任务，做为缓存预热的手段

这个具体原因在Redis-CSDN博客

接下来切入正题：

想象每个服务器都有一个定时任务，都要对数据库或者缓存进行操作

这会带来什么问题？

1：首先最先想到的肯定是资源浪费

2：其次如果我这个定时任务是一个插入操作，那是不是会导致数据库或者缓存有很多的重复数据

再或者是一个修改操作，那肯定会造成结果不唯一的错误

那知道了问题，我们就要去想怎么解决？

解决办法

其实这个问题有点像操作系统中的临界区的问题

如果学过操作系统应该就很容易想到：锁

讲到了锁，那这个锁是一般的锁能锁得住嘛？

锁：

Java 实现锁：synchronized 关键字，这个在学习线程的时候学习过，很容易理解，

不过有个问题，这个synchronized是只对一个JVM有效

我们这里的项目场景可以用这个方法解决嘛？

显然不行，因为你一个synchronized只能锁住一个服务器，有多个服务器同时操作，你还是没有办法

接下来就引出

分布式锁

但是分布式锁这个东西需要考虑的点有很多：

分布式锁的注意事项：

用完锁要释放（腾地方）
锁一定要加过期时间
如果方法执行时间过长，锁提前过期了？
连锁效应：释放掉别人的锁
这样还是会存在多个方法同时执行的情况

解决方案：续期（看门狗机制）

分布式锁概述：

处理多个并发操作的情况，确保在分布式系统中的不同节点（不同服务器）上对共享资源的访问是有序的和安全的

什么意思呢：

有一个房间（数据库），有三台服务器ABC，他们都有这个定时任务，想要进去操作数据库

我们规定，ABC三个服务器需要抢夺一把锁，抢到的才能进入，进去之后并且还需要锁上门

这就和Java多线程很像。

分布式锁的实现：

说了这么多，我们应该怎么保证同一时间只有一个服务器能抢到锁呢？

核心思想：

先来的人先把数据改成自己的标识（服务器 ip），后来的人发现标识已存在，就抢锁失败，继续等待。

等先来的人执行方法结束，把标识清空，其他的人继续抢锁

下面介绍Redis实现分布式锁（我只会这个，等以后会得多了再来补充把）

分布式锁的实现：Redis

主要是基于命令：SETNX key value

塞滕克斯 |文档 --- SETNX | Docs (redis.io)

redis> SETNX mykey "Hello"
(integer) 1
redis> SETNX mykey "World"
(integer) 0
redis> GET mykey
"Hello"

用了setnx将mykey（key）设置为"Hello"（value）之后，不允许再更改了

更改会返回0。

当然如果我们直接用setnx命令去操作就很麻烦，就介绍下面这一个方法：

Redisson 实现分布式锁：

Redisson 是一个 java 操作 Redis 的客户端，提供了大量的分布式数据集来简化对 Redis 的操作和使用，可以让开发者像使用本地集合一样使用 Redis，完全感知不到 Redis 的存在。

还是贴一个官方文档：

https://github.com/redisson/redisson#quick-start

1：引入依赖：

<dependency>
   <groupId>org.redisson</groupId>
   <artifactId>redisson</artifactId>
   <version>3.32.0</version>
</dependency>

2：配置：

package com.usercenter.usercenterproject.config;

/*
Redission的配置
 */

import lombok.Data;
import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
@ConfigurationProperties
@Data
public class RedissionConfiguration {

    private String host;
    private String port;

    @Bean
    public RedissonClient redissonClient(){
        // 1. Create config object
        Config config = new Config();
        String address = String.format("redis://127.0.0.1:6379");
        config.useSingleServer().setAddress(address).setDatabase(3);
        // 2. Create Redisson instance
        // Sync and Async API
        RedissonClient redisson = Redisson.create(config);
        return redisson;
    }

}

这段直接复制官方文档，改一下地址就行。

还需要配置成单机模式config.useSingleServer()

3:Redisson得使用：

a.获取锁对象getLock：

final RLock lock = redissonClient.getLock("shayu:user:recommend:lock");

b.尝试获取锁的操作tryLock：

lock.tryLock(0,-1,TimeUnit.MILLISECONDS)

tryLock 方法会立即返回 false，表示获取锁失败；

而当锁可用时，则尝试获取锁并返回 true，表示成功获取锁。

tryLock这个方法有三个参数：

waitTime：等待时间，即尝试获取锁的最大等待时间。这个参数表示在尝试获取锁时最多愿意等待的时间长度，单位可以是毫秒或者其他时间单位。如果在等待时间内未能成功获取锁，则 tryLock 方法会返回 false。（这个得意思就是其它没有拿到这个锁得服务器，他们不能一直等待，等过了这个waitTime之后就会放弃抢锁）这里的waitTime可以设置为0，因为我们这个定时任务，只要有一个服务器获取了，其它服务器就不能再操作了
leaseTime：租约时间，表示获取锁成功后的租约时长。这个参数指定了成功获取锁后的持有时间长度，即锁的有效期，单位也可以是毫秒或其他时间单位。当锁的持有时间达到租约时长后，系统会自动释放锁。（表示这个获得锁的服务器的最长拥有时间，过了这个拥有时间，这个服务器就必须释放锁）这个leaseTime这里设置为-1，这是因为后面的看门狗机制
unit：时间单位，用于指定 waitTime 和 leaseTime 的时间单位，可以是 TimeUnit 中预定义的时间单位，例如 TimeUnit.MILLISECONDS 表示毫秒。这个参数用于确保 waitTime 和 leaseTime 的时间粒度符合需求。

c.释放锁unlock()：

获取锁之后一定要释放

还有一个点，在释放锁之前要确认一下是否是自己的锁：lock.isHeldByCurrentThread()

        finally {
            if(lock.isHeldByCurrentThread()){
                System.out.println("unlock"+Thread.currentThread().getId());
                lock.unlock();
            }
        }

可以将释放锁这段代码放在finally，因为创建锁需要捕获异常，如果不在finally中释放，就可以会发生这个锁一直存在这种现象。