个人博客


首先,分布式锁和我们平常讲到的锁原理基本一样,目的就是确保在多个线程并发时,只有一个线程在同一刻操作这个业务或者说方法、变量。

在一个进程中,也就是一个jvm或者说应用中,我们很容易去处理控制,在java.util并发包中已经为我们提供了这些方法去加锁,比如synchronized关键字或者Lock锁,都可以处理。

但是如果在分布式环境下,要保证多个线程同时只有1个能访问某个资源,就需要用到分布式锁。这里我们将介绍用Redis的setnx命令来实现分布式锁。

其实目前通常所说的setnx命令,并非单指redis的setnx key value这条命令,这条命令可能会在后期redis版本中删除。

一般代指redis中对set命令加上nx参数进行使用,set这个命令,目前已经支持这么多参数可选:

1
SET key value [EX seconds] [PX milliseconds] [NX|XX]

从 Redis 2.6.12 版本开始, SET 命令的行为可以通过一系列参数来修改:

  • 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 :只在键已经存在时,才对键进行设置操作。

1、示例

注入bean

1
2
3
4
@Bean
public ValueOperations<String, String> stringOperations(StringRedisTemplate redisTemplate) {
return redisTemplate.opsForValue();
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
@RunWith(SpringRunner.class)
@SpringBootTest
@Slf4j
public class SetnxTest {
@Autowired
private ValueOperations<String, String> stringOperations;

@Autowired
private RedisTemplate<String, Object> redisTemplate;

@Test
public void testSetnx() {
// 同时并发5个线程竞争去获取锁
IntStream.range(0, 5).parallel().forEach(i -> {
String uuid = IdUtil.randomUUID();
Boolean lock = stringOperations.setIfAbsent("lock", uuid, 10, TimeUnit.SECONDS);
log.info("是否获取锁:[{}]", lock);
if (!lock) return;
// 获得锁后的操作
// ...

// 最后释放锁
redisTemplate.delete("lock");
});
}
}

这里同时启动5个线程并发往redis中存储lock这个key(key可以自定义,但需要一致),同时设置10秒的过期时间。
setIfAbsent这个函数实现的功能与setnx命令一样,代表如果没有这个key则set成功获取到锁,否则set失败没有获取到锁。
获得锁后进行资源的操作,最后释放锁。

执行效果

1
2
3
4
5
2020-08-13 22:23:48,200 [INFO] [ForkJoinPool.commonPool-worker-9] [net.zhaoxiaobin.redistemplate.SetnxTest:31] [] 是否获取锁:[true]
2020-08-13 22:23:48,278 [INFO] [ForkJoinPool.commonPool-worker-4] [net.zhaoxiaobin.redistemplate.SetnxTest:31] [] 是否获取锁:[false]
2020-08-13 22:23:48,278 [INFO] [ForkJoinPool.commonPool-worker-2] [net.zhaoxiaobin.redistemplate.SetnxTest:31] [] 是否获取锁:[false]
2020-08-13 22:23:48,278 [INFO] [main] [net.zhaoxiaobin.redistemplate.SetnxTest:31] [] 是否获取锁:[false]
2020-08-13 22:23:48,279 [INFO] [ForkJoinPool.commonPool-worker-11] [net.zhaoxiaobin.redistemplate.SetnxTest:31] [] 是否获取锁:[false]

可以看到同时只有1个线程能够获取到锁。

2、总结

使用setnx命令方式虽然操作比较简单方便,但是会有如下问题:

1.当前线程如果获得了锁就不能再重入了(在锁释放前不能再获得锁)。

可以在再次获取锁时,如果锁被占用就get值,判断值是否是当前线程存的随机值,如果是则再次执行set命令重新上锁;当然为了保证原子性这些操作都要用lua脚本来执行。

2.获取锁方式非阻塞,其它线程没有获取到锁就只能失败返回了,只适合于个别业务场景。

可以使用while循环重复执行setnx命令,并设置一个超时时间退出循环。

3.锁过期时间如果设置太短或者拿到锁的线程执行完方法耗时特别长,方法没等执行完,锁就自动释放了,然后别的线程也能拿到锁,导致不安全的操作。类似的还有几种情况:

因为网络延迟,等拿到锁时,锁已经过期了,可以设置超时时间远小于锁自动过期时间来解决。

程序拿到锁后进入GC导致程序暂定,恢复后锁过期了。

Redis所在的机器发生了时钟漂移(Clock Drift),时间向前跳跃导致锁提前过期。

可以尽量把锁自动过期的时间设的冗余一些。但也不能彻底解决。

4.锁自动过期后,第二个线程拿到锁开始操作,第一个拿到锁的等执行完回手就把别人的锁给删了,那么就会产生并发安全问题。

可以在删除锁的时候先get值,判断值是否是当前线程存的随机值,只有相同才执行删锁的操作;当然也要使用lua脚本执行来保证原子性。

5.在Cluster集群模式下,如果redis出现故障,进行主从切换,这个时候主机的锁如果还未同步到从机上,就会导致其他线程同样也可以获取到锁。

分布式锁需要满足的特性

  • 互斥性。
  • 锁超时。
  • 支持阻塞和非阻塞。
  • 可重入性。
  • 高可用。

综上:使用setnx命令来实现分布式锁并不是一个很严谨的方案,如果是Java技术栈,我们可以使用Redisson库来解决以上问题,接下来的文章会介绍如何使用。

参考链接