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

已于 2024-03-07 23:04:36 修改
阅读量1.4k 收藏 22
点赞数 29
文章标签： redis 分布式 wpf java
于 2024-02-06 00:24:58 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：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：

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

问题：

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

5.1 释放别人加的锁

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

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

5.2 解决方案：

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

  1. 通过控制加锁的value值为 唯一值：SET key random PX 5000 NX，其中，random应该是唯一值；
  2. 删除锁的时候，先获取锁的值是否等于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")
}
}

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

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

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

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

再看如下例子：

  1. 客户端1请求锁定节点A、B、C、D、E；
  2. 当对客户端1的响应在路途中时，客户端1进入停止世界的GC；
  3. 所有Redis节点的锁都过期了；
  4. 客户端2获得了节点A、B、C、D、E的锁；
  5. 客户端1完成了GC，并收到了来自Redis节点的响应，表明它成功获得了锁（当进程暂停时，它们被保存在客户端1的内核网络缓冲区）；
  6. 客户端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
关注
Redis——Redis分布式锁原理与实战
庄小焱
03-13 673
分布式应用进行逻辑处理时经常会遇到并发问题。比如一个操作要修改用户的状态，修改状态需要先读出用户的状态，在内存里进行修改，改完了再存回去。如果这样的操作同时进行了，就会出现并发问题，因为读取和保存状态这两个操作不是原子的。（ Wiki 解释：所谓原子操作是指不会被线程调度机制打断的操作；这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch 线程切换。）这个时候就要使用到分布式锁来限制程序并发的执行。
分布式锁——Redis分布式锁
m0_49271078的博客
11-11 276
概述 在高并发环境下，必然会面临多线程对共享资源的竞争问题，如果不进行控制会出现一些异常行为。单机环境下可以使用Synchronized、ReentrantLock等JDK提供的锁来实现多线程对共享资源的互斥访问，但现在的应用大都是集群部署，针对这种跨JVM的情况如何实现来解决互斥访问的问题？这就需要用到分布式锁来进行控制。常见的分布式锁实现方式主要有数据库实现、Redis实现、Zookeeper实现，今天主要对Redis分布式锁进行探究。 Redis 分布式锁 1、加锁流程 SetNX key val
redis - set 命令回顾
为什么我的眼里常含泪水？
03-12 363
SET key value [EX seconds] [PX milliseconds] [NX|XX] 可用版本： >= 1.0.0 时间复杂度： O(1) 将字符串值 value 关联到 key 。 如果 key 已经持有其他值， SET 就覆写旧值， 无视类型。 当 SET 命令对一个带有生存时间（TTL）的键进行设置之后， 该键原有的 TTL 将被清除。 可选参数 从 Redis 2.6.12 版本开始， SET 命令的行为可以通过一系列参数来修改： EX seconds ： 将键的过期时
SET key value [EX seconds] [PX milliseconds] [NX|XX]
weixin_30248399的博客
05-30 1527
SET key value [EX seconds] [PX milliseconds] [NX|XX] 可用版本： >= 1.0.0 时间复杂度： O(1) 将字符串值value关联到key。 如果key已经持有其他值，SET就覆写旧值， 无视类型。 当SET命令对一个带有生存时间（TTL）的键进行设置之后， 该键原有的 TTL 将被清...
SET key value（NX、PX、XX）
zheng2780071070的博客
03-17 7034
转载自：http://redisdoc.com/string/set.html 从 Redis 2.6.12 版本开始， SET 命令的行为可以通过一系列参数来修改： EX seconds ： 将键的过期时间设置为 seconds 秒。 执行 SET key value EX seconds 的效果等同于执行 SETEX key seconds value 。 PX milliseconds ： 将键的过期时间设置为 milliseconds 毫秒。 执行 SET key value.
Redis-SET key value
cxu123321的博客
07-22 1346
SETkeyvalue[EX seconds|PX milliseconds][NX|XX][KEEPTTL] Available since 1.0.0. Time complexity:O(1) Setkeyto hold the stringvalue. Ifkeyalready holds a value, it is overwritten, regardless of its type. Any previous time to live associated wit...
2022年Redis最新面试题- Redis分布式锁
q66562636的博客
05-12 6295
最近整理一份关于Redis常见面试题的，也会根据自己的经验， 标注一些出现的概率，最高5颗★出现的概率最高。比如这样: Redis 最适合的场景, 可以简单的说说吗? 出现概率: ★★★★ 整体目录大概如下: 目录 一、Redis基础知识 1、什么是 Redis, 有哪些优缺点? 2、Redis 最适合的场景, 可以简单的说说吗? 3、Redis 相比 Memcached 有哪些优势？ 4、一个字符串类型的值能存储最大容量是多少？ 5、Redis 读写分离 二、数据结构 1
redis分布式锁的原理与实现【分布式】
weixin_44545838的博客
05-31 2309
分布式锁是指在分布式系统中，为了实现协调和同步访问共享资源，而对分布式环境下的多个进程或线程进行同步的一种机制。它可以保证在分布式环境下各进程访问共享资源的时序一致性和互斥性，避免不同进程之间发生冲突。基于数据库的分布式锁：使用数据库的事务机制来实现分布式锁，通过在数据库插入一个唯一的记录来实现锁定，其他进程尝试并发获取锁时会阻塞等待。基于缓存的分布式锁。
Redis 分布式锁
yb1415185602的博客
08-23 330
但是，使用 zk 临时节点会存在另一个问题：由于 zk 依靠 session 定期的心跳来维持客户端，如果客户端进入长时间的 GC，可能会导致 zk 认为客户端宕机而释放锁，让其他的客户端获取锁，但是客户端在 GC 恢复后，会认为自己还持有锁，从而可能出现多个客户端同时获取到锁的情形。因为如果某个客户端获取到了锁，但是阻塞了很长时间才执行完，比如说超过了 30s，此时可能已经自动释放锁了，此时可能别的客户端已经获取到了这个锁，要是你这个时候直接删除 key 的话会有问题，所以得用随机值加上面的。
redis - set key value [expiration EX seconds|PX milliseconds] [NX|XX]
hai330的博客
11-30 587
**set key value [expiration EX seconds|PX milliseconds] [NX|XX]** EX seconds ： 将键的过期时间设置为 seconds 秒。 执行 SET key value EX seconds 的效果等同于执行 SETEX key seconds value。 PX milliseconds ： 将键的过期时间设置为 milliseconds 毫秒。 执行 SET key value PX milliseconds 的效果等同于执行 PS.
单步调试Redis源码——set key value方法
weixin_37152234的博客
05-16 996
为何redis能做到每秒几十万上百万的qps，为何redis让我们爱不释手、欲罢不能，请观看今晚这篇文章，走进redis之set方法为何快而不持久。 小编相信大家都或多或少用过redis，如果你没用过，那你是不是就得emo一会了，这么好用的东西都没接触过，小编只想说，你们公司还缺不缺人。 今晚这篇文章我们一起来了解一下，redis的set方法究竟是如何运行的，小编将带大家一起以redis的set key value方法为例单步调试一下redis(不会的偶尔也直接跳过)。 按惯例，先说调试工具 cl.
java set key value_Java JavaTuples setKey()用法及代码示例
weixin_29355377的博客
02-26 543
org.javatuples中的setKey()方法用于设置KeyValue Class对象的键。此方法只能与javatuples库的KeyValue类对象一起使用。它返回另一个KeyValueClassObject，其Key作为参数传递为元素，并且返回先前KeyValueClassObject的值。方法声明：public KeyValue setKey(X key)用法:KeyValue Ke...
Redis笔记_5
kick5578的专栏
04-16 734
第五章 5.3 查找IP所属城市及国家 使用第三方提供的IP所属城市地区库, 如http://www.ip138.com/ 使用的redis api Redis Hset 命令用于为哈希表中的字段赋值 。 如果哈希表不存在，一个新的哈希表被创建并进行 HSET 操作。 如果字段已经存在于哈希表中，旧值将被覆盖。 语法 redis Hset 命令基本语
Redis setnx和set(key,value,nxxx,expx,time)
热门推荐
qq_42459467的博客
08-11 2万+
redis setnx和set(key,value,nxxx,expx,time)
详细解释Redis的SET NX命令
最新发布
常备不懈
06-30 3236
`SET NX` 命令是 Redis 中用于实现分布式锁的一个重要命令。
set nx px
varyall的专栏
06-14 759
1 介绍 这篇博文讲介绍如何一步步构建一个基于Redis的分布式锁。会从最原始的版本开始，然后根据问题进行调整，最后完成一个较为合理的分布式锁。 本篇文章会将分布式锁的实现分为两部分，一个是单机环境，另一个是集群环境下的Redis锁实现。在介绍分布式锁的实现之前，先来了解下分布式锁的一些信息。 2 分布式锁 2.1 什么是分布式锁？ 分布式锁是控制分布式系统或不同系统之间共同访问共享资源的一种锁实现，如果不同的系统或同一个系统的不同主机之间共享了某个资源时，往往需要互斥来防止彼此干扰来保证一致性。
Redis分布式锁两种实现策略：SET vs SETNX+GETSET
- `SET key value [EX seconds] [PX milliseconds] NX`: 这个命令用于在指定时间内（以秒或毫秒为单位）设置键值对，如果键不存在（NX选项），则设置成功并返回OK。客户端尝试设置键值对，若成功则获取到锁。当...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值