“SET key value [EX seconds] [PX milliseconds] [NX|XX]“和redis分布式锁

钱多多_qdd

已于 2024-03-07 23:04:36 修改

阅读量1.2k

点赞数 29

文章标签： redis 分布式 wpf java

于 2024-02-06 00:24:58 首次发布

本文链接：https://blog.csdn.net/moneywenxue/article/details/136049418

版权

一、可选参数介绍

EX second ：设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。
PX millisecond ：设置键的过期时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。
NX ：只在键不存在时，才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 。
XX ：只在键已经存在时，才对键进行设置操作。

因为 SET 命令可以通过参数来实现和 SETNX 、 SETEX 和 PSETEX 三个命令的效果，所以将来的 Redis 版本可能会废弃并最终移除 SETNX 、 SETEX 和 PSETEX 这三个命令。

注意：

setnx命令不建议使用；太老了，已过时；
建议使用set命令，+nx参数；

set （ex,nx）是原子性的命令；

在Springboot项目中使用Redis提供给Lua的脚本

二、其他介绍

2.1 可用版本：

大于1.0.0

2.2 返回值

在 Redis 2.6.12 版本以前， SET 命令总是返回 OK 。
从 Redis 2.6.12 版本开始， SET 在设置操作成功完成时，才返回 OK 。
如果设置了 NX 或者 XX ，但因为条件没达到而造成设置操作未执行，那么命令返回空批量回（NULL Bulk Reply）。

三、命令行实操

# 对不存在的键进行设置

redis 127.0.0.1:6379> SET key "value"
OK

redis 127.0.0.1:6379> GET key
"value"


# 对已存在的键进行设置

redis 127.0.0.1:6379> SET key "new-value"
OK

redis 127.0.0.1:6379> GET key
"new-value"


# 使用 EX 选项

redis 127.0.0.1:6379> SET key-with-expire-time "hello" EX 10086
OK

redis 127.0.0.1:6379> GET key-with-expire-time
"hello"

redis 127.0.0.1:6379> TTL key-with-expire-time
(integer) 10069


# 使用 PX 选项

redis 127.0.0.1:6379> SET key-with-pexpire-time "moto" PX 123321
OK

redis 127.0.0.1:6379> GET key-with-pexpire-time
"moto"

redis 127.0.0.1:6379> PTTL key-with-pexpire-time
(integer) 111939


# 使用 NX 选项

redis 127.0.0.1:6379> SET not-exists-key "value" NX
OK      # 键不存在，设置成功

redis 127.0.0.1:6379> GET not-exists-key
"value"

redis 127.0.0.1:6379> SET not-exists-key "new-value" NX
(nil)   # 键已经存在，设置失败

redis 127.0.0.1:6379> GEt not-exists-key
"value" # 维持原值不变


# 使用 XX 选项

redis 127.0.0.1:6379> EXISTS exists-key
(integer) 0

redis 127.0.0.1:6379> SET exists-key "value" XX
(nil)   # 因为键不存在，设置失败

redis 127.0.0.1:6379> SET exists-key "value"
OK      # 先给键设置一个值

redis 127.0.0.1:6379> SET exists-key "new-value" XX
OK      # 设置新值成功

redis 127.0.0.1:6379> GET exists-key
"new-value"


# NX 或 XX 可以和 EX 或者 PX 组合使用

redis 127.0.0.1:6379> SET key-with-expire-and-NX "hello" EX 10086 NX
OK

redis 127.0.0.1:6379> GET key-with-expire-and-NX
"hello"

redis 127.0.0.1:6379> TTL key-with-expire-and-NX
(integer) 10063

redis 127.0.0.1:6379> SET key-with-pexpire-and-XX "old value"
OK

redis 127.0.0.1:6379> SET key-with-pexpire-and-XX "new value" PX 123321
OK

redis 127.0.0.1:6379> GET key-with-pexpire-and-XX
"new value"

redis 127.0.0.1:6379> PTTL key-with-pexpire-and-XX
(integer) 112999


# EX 和 PX 可以同时出现，但后面给出的选项会覆盖前面给出的选项

redis 127.0.0.1:6379> SET key "value" EX 1000 PX 5000000
OK

redis 127.0.0.1:6379> TTL key
(integer) 4993  # 这是 PX 参数设置的值

redis 127.0.0.1:6379> SET another-key "value" PX 5000000 EX 1000
OK

redis 127.0.0.1:6379> TTL another-key
(integer) 997   # 这是 EX 参数设置的值

四、锁使用模式

命令 SET resource-name anystring NX EX max-lock-time 是一种在 Redis 中实现锁的简单方法。
客户端执行以上的命令：

如果服务器返回 OK ，那么这个客户端获得锁;
如果服务器返回 NIL ，那么客户端获取锁失败，可以在稍后再重试;

设置的过期时间到达之后，锁将自动释放。

但是这样，锁仍然存在问题。

五、锁优化

修复setnx问题后，我们继续分析有另外一个进程进入的情况，考虑按时间顺序如下场景：
如果锁有效时间10s：

进程A加锁成功，开始操作，操作时间过了锁有效期；
进程B申请加锁，开始操作；
进程A释放锁（进程B的锁被释放掉了）；

问题：

锁过期时间控制：如果一个进程执行时间过长，导致锁超期释放，别的进程可获取锁，两个进程同时拥有一把锁，操作同一份RMW 代码；
释放别人的锁：进程A释放锁的时候，把别的进程的锁释放掉了；

5.1 释放别人加的锁

上述问题，图示如下：
在这里插入图片描述

进程A加锁成功；
进程A执行时间超出锁有效期，进程B获取锁；
进程A执行完成，释放了B进程加的锁；

5.2 解决方案：

可以通过以下修改，让这个锁实现更健壮：

通过控制加锁的value值为唯一值：SET key random PX 5000 NX，其中，random应该是唯一值；
删除锁的时候，先获取锁的值是否等于random值，等于则释放，为了保证原子性采用lua脚
本；

lua脚本：

//释放锁 比较random是否相等，避免误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
	return redis.call("del",KEYS[1])
else
	return 0
end

整体代码开起来如下：

function writeData(filename, data) {
	uuid = UUID.random().tostring;
	var lock = redis.set(filename,uuid,px,5000,NX);
if (!lock) {
	throw 'Failed to acquire lock';
}
try {
	var file = storage.readFile(filename);
	var updated = updateContents(file, data);
	storage.writeFile(filename, updated);
} finally {
	redis.eval("if redis.call("get",KEYS[1]) == ARGV[1] then
	return redis.call("del",KEYS[1])
else
	return 0
end")
}
}

这段代码看起来，解决了我们想到的很多问题，事实上，很多项目中依然采用着，除了上述我们提及过：锁过期时间与线程执行时间不好确定之外，我们继续分析，还有什么问题：

锁过期时间；
redis不能是主从部署方式；
更宽泛的说来，不支持很多锁的功能：比如，是否公平，是否可重入；

其实redisson已经帮我们提供了更加健壮简洁的锁实现。

5.3 redis部署方式：

redis部署方式：

单机模式；
主从模式；
哨兵模式；
和集群模式；

以下是这几种部署方式的概述：

单机模式。这是最简单的方式，直接部署一个 Redis 实例，适用于对可用性和性能要求不高的场景；
主从模式。在这种模式下，部署一台 Redis 主服务（Master）和多台 Redis 从服务（Slave）。Master 负责处理写操作，而 Slave 专门用于读操作。Master 会将所有写操作同步到所有 Slave。如果 Master 服务器宕机，Slave 可以升级为主服务器。
哨兵模式。在哨兵模式下，一个哨兵集群负责监控主节点和从节点。如果检测到主节点故障，系统可以自动将从节点晋升为主节点。这种方式提高了故障恢复的自动化程度，但仍存在内存容量和写入性能的限制。
集群模式。在 Redis 3.x 版本之后，推出了 Cluster 集群模式。这种模式通过数据分片和节点的水平扩展，实现了更高效的内存利用和写入性能。每个节点都负责一部分数据，并通过内部通信机制来处理数据操作。

主从是有延迟性的：因为Master 负责处理写操作，而 Slave 专门用于读操作；读和写之间是有延时的。

redis锁，最好不要用主从、或者哨兵模式，会有延迟；有可能主节点加锁成功，但还没同步到从节点，此时另一个线程向从节点读取，发现没有，加锁，导致两个线程都拿到了锁

五、Redisson

Redisson 是架设在 Redis 基础上的一个 Java驻内存数据网格框架, 充分利用 Redis 键值数据库提供的一系列优势, 基于 Java 使用工具包中常用接口, 为使用者提供了一系列具有分布式特性的常用工具类。其中就提供了一种RedLock的加锁算法和实现，讨论之前，我们可以先分析单机版的Redisson如何实现一个分布式锁。

RedLock官方介绍: Distributed locks with Redis – Redis

由于 Redisson自身太过于复杂, 设计的 API 调用大多用 Netty 相关, 所以本文只对如何加锁、如何实现重入锁，释放锁进行讨论.

5.1 加锁流程

在这里插入图片描述

5.2 解锁流程

在这里插入图片描述

5.3 Redlock

5.3.1 Redlock 算法介绍

部署多台 Redis, 各实例之间相互独立, 不存在主从复制或者其他集群协调机制。
使用方式大体如下：

RLock lock1 = redissonInstance1.getLock("lock1");
RLock lock2 = redissonInstance2.getLock("lock1");
RLock lock3 = redissonInstance3.getLock("lock1");
RedissonRedLock lock = new RedissonRedLock(lock1, lock2, lock3);
// 同时加锁：lock1 lock1 lock1
// 红锁在大部分节点上加锁成功就算成功。
lock.lock();
...
lock.unlock();

原理：
加入设置节点数N=5，所以我们需要在不同的计算机或虚拟机上运行5个Redis主站，以确保它们会以一种基本独立的方式失败。

为了获得锁，客户端执行以下操作：

获取当前的时间，以毫秒为单位；
依次在所有N个实例中获取锁，在所有实例中使用相同的键名和随机值。在步骤2中，当在每个实例中设置锁时，客户端使用一个与总的锁自动释放时间相比很小的超时来获取它。例如，如果自动释放时间是10秒，超时可以在~ 5-50毫秒范围内。这可以防止客户端在试图与Redis节点对话时长时间受阻：如果一个实例不可用，我们应该尽快尝试与下一个实例对话；
客户端通过从当前时间减去步骤1中获得的时间戳，计算出获得锁所需的时间。如果并且只有当客户端能够在大多数实例（至少3个）中获取锁，并且获取锁的总时间小于锁的有效期，锁才被认为是被获取；
如果锁被获取，其有效性时间被认为是初始有效性时间减去经过的时间，如步骤3中计算的那样；
如果客户端由于某种原因未能获得锁（要么它无法锁定N/2+1个实例，要么有效性时间为负数），它将尝试解锁所有的实例（甚至是它认为无法锁定的实例）；

5.3.2 Redlock 算法是否安全（了解即可）

分布式系统研究员Martin Kleppmann曾对 RedLock算法深入分析并强烈反对在生产中使用，其主要原因就是redlock的实现依赖了服务器的本地时钟。

如下例子，还是5个节点，Redlock失效：

客户端1获得了A、B、C节点上的锁，由于网络问题，无法到达D和E；
节点C上的时钟向前跳动，导致锁过期；
客户端2获得了节点C、D、E的锁，由于网络问题，A和B不能被联系到；
客户端1和2现在都认为他们持有锁；

也或者，在第二步骤，节点c如果出现宕机，恢复后没有之前的数据，客户端2也可能获取到锁。

再看如下例子：

客户端1请求锁定节点A、B、C、D、E；
当对客户端1的响应在路途中时，客户端1进入停止世界的GC；
所有Redis节点的锁都过期了；
客户端2获得了节点A、B、C、D、E的锁；
客户端1完成了GC，并收到了来自Redis节点的响应，表明它成功获得了锁（当进程暂停时，它们被保存在客户端1的内核网络缓冲区）；
客户端1和2现在都认为他们持有该锁；

六、RedissonLock类

问：有没有哪个工具类有SET key value [EX seconds] [PX milliseconds] [NX]的api呢？
——答：在 Java 中，Redisson提供了一个RedissonLock类，它有类似于SET key value [EX seconds] [PX milliseconds] [NX]的 API 。

以下是一个使用RedissonLock实现上述功能的简单示例：

import org.redisson.Redisson;
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

import java.util.concurrent.TimeUnit;

@Component
public class RedisLock {

    @Autowired
    private RedissonClient redissonClient;

    private Config config;

    // 在构造函数中初始化 RedissonClient
    public RedisLock() {
        // 使用配置类 Config 来配置 Redisson 客户端
        config = new Config();
        config.useSingleServer().setAddress("redis://127.0.0.1:6379");
        // 创建 Redisson 客户端实例
        redissonClient = Redisson.create(config);
    }

    // 获取锁并设置过期时间的方法
    public void lock(String lockName, int expireTime, TimeUnit timeUnit) {
        RLock lock = redissonClient.getLock(lockName);
        lock.lock(expireTime, timeUnit);
    }

    // 释放锁的方法
    public void unlock(String lockName) {
        RLock lock = redissonClient.getLock(lockName);
        lock.unlock();
    }
}

在上述代码中，首先通过@Autowired注解注入RedissonClient实例，然后在lock()方法中通过redissonClient.getLock(lockName)获取锁，其中lockName是锁的名称，可根据实际需求进行调整，最后使用lock.unlock()方法释放锁。

6.1 RedissonLock#lock源码

<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
        return evalWriteAsync(getRawName(), LongCodec.INSTANCE, command,
                "if (redis.call('exists', KEYS[1]) == 0) then " +
                        "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                        "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                        "return nil; " +
                        "end; " +
                        "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
                        "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                        "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                        "return nil; " +
                        "end; " +
                        "return redis.call('pttl', KEYS[1]);",
                Collections.singletonList(getRawName()), unit.toMillis(leaseTime), getLockName(threadId));
    }

在这里插入图片描述

RedissonLock锁：

key的组成：uuid+线程号；
value：锁的重入次数，例如：1,2,3；

钱多多_qdd

关注

29
点赞
踩
22

收藏

觉得还不错? 一键收藏
0
评论
“SET key value [EX seconds] [PX milliseconds] [NX|XX]“和redis分布式锁

在 Java 中，Redisson提供了一个RedissonLock类，它有类似于SET key value [EX seconds] [PX milliseconds] [NX]的 API 。
复制链接

扫一扫