面试问了分布式锁,你会答吗?

数据库 其他数据库
在数据库中创建一个锁表,并且在需要的字段上创建唯一索引,使用锁的时候就插入数据,插入成功则获得锁,执行结束后,就删除数据。也可以加上version控制,使之成为乐观锁。

哈喽,大家好,我是指北君。

分布式锁在很多面试中都会提及,那么我们到底要不要了解呢?

1. 前言

分布式应用中,有时我们需要一个方法在同一时间只能被一个线程执行。此时我们有可能会使用到分布式锁。

分布式锁需要具备以下特征:

  • 互斥性同一时刻锁只能被一个线程持有。
  • 超时释放超时释放主要是用来避免死锁,防止不必要的线程等待和资源浪费
  • 可重入性一个线程在持有锁的情况下,可以再次请求加锁
  • 高性能,高可用加锁释放锁的操作尽量使用更少的资源,提高性能。同时也要保证高可用,防止分布式锁意外失效

目前比较多的分布式锁有下面的方案:

  • 基于数据库实现分布式锁
  • 基于缓存(redis, Hazelcast)等实现分布式锁
  • 基于Zookeeper实现分布式锁

2. 数据库分布式锁

2.1基于表记录的分布式锁

在数据库中创建一个锁表,并且在需要的字段上创建唯一索引,使用锁的时候就插入数据,插入成功则获得锁,执行结束后,就删除数据。也可以加上version控制,使之成为乐观锁。

  • 获取锁:成功插入数据
  • 执行业务逻辑
  • 释放锁:删除数据

2.2基于数据库行锁的分布式锁

使用select * For update来获取数据库数据锁, where之后的条件加入唯一索引,则表示使用了行锁。其分布式锁使用顺序如下。

  • 获取锁:SELECT * FROM database_lock WHERE id = 1 FOR UPDATE;。
  • 执行业务逻辑。
  • 释放锁:COMMIT。

3.Zookeeper分布式锁

Zookeepe可以实现分布式锁主要是因为多个线程去Zookpeeper中创建同一个节点时,只有一个线程可以创建成功。

Zookeeper中有临时节点,持久化节点。其中临时节点在服务端session失效后,节点就会被删除。相对而言,持久化节点在服务端session失效后,也不会被删除,而是需要客户端主动删除。

在上述类型系节点之后增加一个数字后缀,即路径+数字后缀,这样可以保证其唯一性和有序性。

其分布式锁实现原理如下:

  • 创建一个lock目录给分布式锁使用
  • 某个线程想要获取锁就在此目录下创建临时顺序节点
  • 获取此目录下的所有子节点,然后查找比自己序号小的节点,如果不存在,则当前线程创建的节点是最小节点,此时获得锁。
  • 其他线程想要获取锁,同样是创建临时有序节点,如果是最小序号节点则获得锁,否则监听比自己小的次小节点。
  • 持有分布式锁的线程操作完成之后,删除自己的临时节点,次大节点监听到变更事件之后,判断自己是最小序号节点的话,则获得锁。

Zookeeper实现分布式锁具有高可用,可重入,阻塞等特点,由于临时节点在客户端断开的时候就会被自动删除,所以不用担心死锁问题。但是频繁删除和创建节点,性能上会比Redis分布式锁低。

4 Redis分布式锁

4.1 SETNX

setnx命令只会在key不存在的情况下将key设置为value值, 其中key和 value值均可以设置成和业务相关的的命名。但是不满足超时释放的要求。

如果使用expire设置过期时间,也有可能在setnx成功后,由于各种原因,expire没有执行成功,从而导致锁不能超时释放。

4.2 SETNX 扩展命令

set key value [EX seconds] [PX milliseconds] [NX|XX]
#EX 设置过期时间,单位为秒 set lock VALUE EX 10
#PX 设置过期时间,单位为毫秒 set lock VALUE PX 10000
#NX key不存在时才设置key的值 set lock VALUE EX 10 NX
#XX key存在时才设置key SET lock VALUE EX 10 XX

set 扩展命令可以完全取代 SETNX, SETEX, PSETEX 等功能。

可以使用set扩展功能完成设置过期时间, 并且是原子操作。

上述分布式锁也有一些问题:

  • 如果线程获取锁之后,执行时间过长,锁提前释放。
  • 如果线程A未执行完操作,锁超时释放,此时线程B又获取了锁。线程B持有锁,但是A线程有可能执行DEL操作释放锁。

需要避免在长时间执行的任务中使用上述分布式锁,而且未按时执行完的线程不影响其最终结果。另外可以在锁的value设置一些唯一值,删除key之前验证是否持有锁。并且验证和删除需要使用Lua脚本保证其删除操作的原子性。

上述分布式锁还需要解决一个可重入性的问题。

4.3 Redisson 分布式锁

Redisson是基于Redis的Java内存数据网格,充分利用了Redis键值数据库提供的一系列优势。同时提供功能丰富的分布式锁。

Resisson内部会有一个监控锁的守护线程,在redisson实例被关闭前,不断延长锁的有效期。并且可以自定义超时检查时间间隔,同时还可以指定加锁时间。另外还支持公平锁(Fair Lock),联锁(MultiLock),红锁(RedLock),读写锁(ReadWriteLock)以及RSemaphore和RCountDownLatch等类似Java提供的各种多线程工具等。

其中RedLock是基于多个Redis集群关联的锁,可以大大提高锁的可用性及安全性。

关于Redisson,我们后续的文章会继续讲到,尽请期待!

分布式应用中,有时我们需要一个方法在同一时间只能被一个线程执行。此时我们有可能会使用到分布式锁。​

责任编辑:武晓燕 来源: Java技术指北
相关推荐

2023-11-10 08:44:13

分布式锁分布式系统

2024-01-09 08:20:05

2022-05-18 10:38:51

Redis分布式锁数据

2021-10-09 11:34:59

MySQL分布式锁库存

2023-01-12 08:24:45

ZookeeperZK服务器

2019-06-19 15:40:06

分布式锁RedisJava

2021-07-26 11:09:46

Redis分布式技术

2016-11-02 12:06:27

分布式系统大数据

2021-07-16 07:57:34

ZooKeeperCurator源码

2019-02-26 09:51:52

分布式锁RedisZookeeper

2018-07-17 08:14:22

分布式分布式锁方位

2022-08-04 08:45:50

Redisson分布式锁工具

2021-11-26 06:43:19

Java分布式

2018-11-27 16:17:13

分布式Tomcat

2022-08-11 18:27:50

面试Redis分布式锁

2020-03-12 10:06:32

Redis分布式锁两种

2021-07-06 08:37:29

Redisson分布式

2019-05-28 08:56:40

PythonCPUThread

2022-01-06 10:58:07

Redis数据分布式锁

2017-10-24 11:28:23

Zookeeper分布式锁架构
点赞
收藏

51CTO技术栈公众号