redis的setnx锁到了超时时间失效,并发的问题

本文介绍如何使用Redis的SETNX命令实现分布式锁,并提供了一个Python示例代码。文章详细解释了如何利用SETNX命令的特性避免死锁问题。

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

使用Redis的 SETNX 命令可以实现分布式锁,下文介绍其实现方法。

SETNX命令简介

命令格式

SETNX key value

将 key 的值设为 value,当且仅当 key 不存在。 
若给定的 key 已经存在,则 SETNX 不做任何动作。 
SETNX 是SET if Not eXists的简写。

返回值

返回整数,具体为 
- 1,当 key 的值被设置 
- 0,当 key 的值没被设置

例子

redis> SETNX mykey “hello” 
(integer) 1 
redis> SETNX mykey “hello” 
(integer) 0 
redis> GET mykey 
“hello” 
redis>

使用SETNX实现分布式锁

多个进程执行以下Redis命令:

SETNX lock.foo <current Unix time + lock timeout + 1>

如果 SETNX 返回1,说明该进程获得锁,SETNX将键 lock.foo 的值设置为锁的超时时间(当前时间 + 锁的有效时间)。 
如果 SETNX 返回0,说明其他进程已经获得了锁,进程不能进入临界区。进程可以在一个循环中不断地尝试 SETNX 操作,以获得锁。

解决死锁

考虑一种情况,如果进程获得锁后,断开了与 Redis 的连接(可能是进程挂掉,或者网络中断),如果没有有效的释放锁的机制,那么其他进程都会处于一直等待的状态,即出现“死锁”。

上面在使用 SETNX 获得锁时,我们将键 lock.foo 的值设置为锁的有效时间,进程获得锁后,其他进程还会不断的检测锁是否已超时,如果超时,那么等待的进程也将有机会获得锁。

然而,锁超时时,我们不能简单地使用 DEL 命令删除键 lock.foo 以释放锁。考虑以下情况,进程P1已经首先获得了锁 lock.foo,然后进程P1挂掉了。进程P2,P3正在不断地检测锁是否已释放或者已超时,执行流程如下:

  • P2和P3进程读取键 lock.foo 的值,检测锁是否已超时(通过比较当前时间和键 lock.foo 的值来判断是否超时)
  • P2和P3进程发现锁 lock.foo 已超时
  • P2执行 DEL lock.foo命令
  • P2执行 SETNX lock.foo命令,并返回1,即P2获得锁
  • P3执行 DEL lock.foo命令将P2刚刚设置的键 lock.foo 删除(这步是由于P3刚才已检测到锁已超时)
  • P3执行 SETNX lock.foo命令,并返回1,即P3获得锁
  • P2和P3同时获得了锁

从上面的情况可以得知,在检测到锁超时后,进程不能直接简单地执行 DEL 删除键的操作以获得锁。

为了解决上述算法可能出现的多个进程同时获得锁的问题,我们再来看以下的算法。 
我们同样假设进程P1已经首先获得了锁 lock.foo,然后进程P1挂掉了。接下来的情况:

  • 进程P4执行 SETNX lock.foo 以尝试获取锁
  • 由于进程P1已获得了锁,所以P4执行 SETNX lock.foo 返回0,即获取锁失败
  • P4执行 GET lock.foo 来检测锁是否已超时,如果没超时,则等待一段时间,再次检测
  • 如果P4检测到锁已超时,即当前的时间大于键 lock.foo 的值,P4会执行以下操作 
    GETSET lock.foo <current Unix timestamp + lock timeout + 1>
  • 由于 GETSET 操作在设置键的值的同时,还会返回键的旧值,通过比较键 lock.foo 的旧值是否小于当前时间,可以判断进程是否已获得锁
  • 假如另一个进程P5也检测到锁已超时,并在P4之前执行了 GETSET 操作,那么P4的 GETSET 操作返回的是一个大于当前时间的时间戳,这样P4就不会获得锁而继续等待。注意到,即使P4接下来将键 lock.foo 的值设置了比P5设置的更大的值也没影响。

另外,值得注意的是,在进程释放锁,即执行 DEL lock.foo 操作前,需要先判断锁是否已超时。如果锁已超时,那么锁可能已由其他进程获得,这时直接执行 DEL lock.foo 操作会导致把其他进程已获得的锁释放掉。

程序代码

用以下Python代码来实现上述的使用 SETNX 命令作分布式锁的算法。

LOCK_TIMEOUT = 3
lock = 0
lock_timeout = 0
lock_key = 'lock.foo'

# 获取锁
while lock != 1:
    now = int(time.time())
    lock_timeout = now + LOCK_TIMEOUT + 1
    lock = redis_client.setnx(lock_key, lock_timeout)
    if lock == 1 or (now > int(redis_client.get(lock_key))) and now > int(redis_client.getset(lock_key, lock_timeout)):
        break
    else:
        time.sleep(0.001)

# 已获得锁
do_job()

# 释放锁
now = int(time.time())
if now < lock_timeout:
    redis_client.delete(lock_key)

原文链接:http://blog.csdn.net/lihao21/article/details/49104695
### Redis SETNX 实现可重入分布式 #### 可重入分布式的概念 可重入是指同一个线程可以多次获取同一把而不会发生死的情况。这种特性允许在一个方法调用另一个加的方法时,能够正常执行而不被自己阻塞。 在 Redis 中,通过 `SETNX` 命令配合其他逻辑可以实现这一功能。具体来说,可以通过为每个设置唯一的标识符(通常是一个随机字符串),并记录当前持有的线程 ID 或者请求方的信息来支持可重入性[^1]。 --- #### 使用 SETNX 和唯一标识符实现可重入 为了使具备可重入能力,需要满足以下几个条件: 1. 必须绑定到特定的客户端实例上。 2. 客户端尝试再次获取已持有的时不应失败。 3. 当某个客户端释放时,只有该客户端才能成功解。 以下是具体的实现方式: - **创建时**:使用 `SETNX` 设置键值对,并附带一个唯一标识符作为值。如果键已经存在,则表示已被占用;否则,成功创建。 - **验证归属权**:每次操作前都需要确认当前是否由本客户端持有(即比较存储的值与本地保存的唯一标识符)。 - **增加计数器**:对于同一线程重复获取相同名称的,在内存中维护一个计数器变量用于跟踪嵌套层数。 - **删除时**:仅当计数器减至零时才真正移除 Redis 上对应的键。 --- #### Java 代码示例 以下展示了一个基于 Jedis 库的简单实现方案: ```java import redis.clients.jedis.Jedis; public class ReentrantRedisLock { private final String lockKey; private final String identifier; // 唯一标识符 private int reentryCount = 0; // 记录重入次数 private static final long LOCK_EXPIRE_TIME_MS = 10 * 1000L; // 过期时间 (毫秒) public ReentrantRedisLock(String lockKey, String identifier) { this.lockKey = lockKey; this.identifier = identifier; } /** * 尝试获取 */ public boolean tryAcquire(Jedis jedis) { if (reentryCount > 0) { // 如果已经是定状态则直接更新计数器 reentryCount++; System.out.println("Reentered the lock."); return true; } String result = jedis.set(lockKey, identifier, "NX", "PX", LOCK_EXPIRE_TIME_MS); if ("OK".equals(result)) { // 成功获取 reentryCount = 1; System.out.println("Successfully acquired the lock."); return true; } else { String currentIdentifier = jedis.get(lockKey); // 获取现有的拥有者ID if (identifier.equals(currentIdentifier)) { // 若发现此属于当前进程,则视为重新进入 reentryCount++; System.out.println("Reentered an already held lock."); return true; } else { System.out.println("Failed to acquire the lock as it is owned by another process."); return false; } } } /** * 释放 */ public void release(Jedis jedis) { if (reentryCount <= 0) { throw new IllegalStateException("Cannot release a non-acquired or fully released lock"); } reentryCount--; if (reentryCount == 0) { // 只有最后一次退出时才会实际清除 String script = "if redis.call('get', KEYS[1]) == ARGV[1] then " + "return redis.call('del', KEYS[1]) " + "else " + "return 0 end"; Object evalResult = jedis.eval(script, java.util.Collections.singletonList(lockKey), java.util.Collections.singletonList(identifier)); if ((Long)evalResult != 1L){ System.err.println("Warning: Failed to delete lock due to mismatched identifiers!"); } else{ System.out.println("Released the lock successfully."); } } else { System.out.println("Decrementing reentry count but not releasing yet..."); } } } ``` 上述代码片段展示了如何利用 Redis 的 `SETNX` 结合 Lua 脚本来安全地管理可重入及其生命周期[^2][^3]。 --- #### 注意事项 1. **超时保护**:为了避免死风险,建议始终设定合理的自动失效期限 (`EXPIRE`) 来防止因程序崩溃而导致永久挂起的现象。 2. **高并发场景下的优化**:考虑到网络延迟等因素可能影响性能表现,应考虑批量处理指令或将多个相关联的动作封装成单次事务提交给服务器执行。 ---
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值