对于一个单机的系统,我们可以通过synchronized或者ReentrantLock等这些常规的加锁方式来实现,然而对于一个分布式集群的系统而言,单纯的本地锁已经无法解决问题,所以就需要用到分布式锁了,通常我们都会引入三方组件或者服务来解决这个问题,比如数据库、Redis、Zookeeper等。
通常来说,分布式锁要保证互斥性、不死锁、可重入等特点
互斥性指的是对于同一个资源,任意时刻,都只有一个客户端能持有锁
不死锁指的是必须要有锁超时这种机制,保证在出现问题的时候释放锁,不会出现死锁的问题
可重入指的是对于同一个线程,可以多次重复加锁
数据库实现分布式锁
数据库的话可以使用乐观锁或者悲观锁的实现方式。
乐观锁通常就是数据库中我们会有一个版本号,更新数据的时候通过版本号来更新,这样的话效率会比较高,悲观锁则是通过for update的方式,但是会带来很多问题,因为他是一个行级锁,高并发的情况下可能会导致死锁、客户端连接超时等问题,一般不推荐使用这种方式。
Redis实现分布式锁
Redis是通过set命令来实现,在2.6.2版本之前,实现方式可能是这样:
setNx(key, value); expire(key, seconds);
setNX命令代表当key不存在时返回成功,否则返回失败。
但是这种实现方式把加锁和设置过期时间的步骤分成两步,他们并不是原子操作,如果加锁成功之后程序崩溃、服务宕机等异常情况,导致没有设置过期时间,那么就会导致死锁的问题,其他线程永远都无法获取这个锁。
之后的版本中,Redis提供了原生的set命令,相当于两命令合二为一,不存在原子性的问题,当然也可以通过lua脚本来解决。
set key value NX EX 10
- EX 代表过期时间为秒,PX则为毫秒,比如上面示例中为10秒过期
虽然set解决了原子性的问题,但是还是会存在两个问题。
锁超时问题
比如客户端A加锁同时设置超时时间是3秒,结果3s之后程序逻辑还没有执行完成,锁已经释放。客户端B此时也来尝试加锁,那么客户端B也会加锁成功。
这样的话,就导致了并发的问题,如果代码幂等性没有处理好,就会导致问题产生
针对锁超时的问题,我们可以根据平时业务执行时间做大致的评估,然后根据评估的时间设置一个较为合理的超时时间,这样能一大部分程度上避免问题
自动续租,通过其他的线程为将要过期的锁延长持有时间
可以让获得锁的线程开启一个守护线程,用来给快要过期的锁“续航”。
- 当过去了29秒,线程A还没执行完,这时候守护线程会执行expire指令,为这把锁“续命”20秒。守护线程从第29秒开始执行,每20秒执行一次。
- 当线程A执行完任务,会显式关掉守护线程。
锁误删除
还是类似的问题,客户端A加锁同时设置超时时间3秒,结果3s之后程序逻辑还没有执行完成,锁已经释放。客户端B此时也来尝试加锁,这时客户端A代码执行完成,执行释放锁,结果释放了客户端B的锁
怎么避免这种情况呢?可以在del释放锁之前做一个判断,验证当前的锁是不是自己加的锁。
至于具体的实现,可以在加锁的时候把当前的线程ID当做value,并在删除之前验证key对应的value是不是自己线程的ID。
加锁:
加锁:
String threadId = Thread.currentThread().getId()
set(key,threadId ,30,NX)
解锁:
if(threadId .equals(redisClient.get(key))){
del(key)
}
但是,这样做又隐含了一个新的问题,判断和释放锁是两个独立操作,不是原子性。
这一块要用Lua脚本来实现:
String luaScript = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
redisClient.eval(luaScript , Collections.singletonList(key), Collections.singletonList(threadId));
Zookeeper实现分布式锁
Zookeeper是通过创建临时顺序节点的方式来实现。
- 当需要对资源进行加锁时,实际上就是在父节点之下创建一个临时顺序节点
- 客户端A来对资源加锁,首先判断当前创建的节点是否为最小节点,如果是,那么加锁成功,后续加锁线程阻塞等待
- 此时,客户端B也来尝试加锁,由于客户端A已经加锁成功,所以客户端B发现自己的节点并不是最小节点,就会去取到上一个节点,并且对上一节点注册监听
- 当客户端A操作完成,释放锁的操作就是删除这个节点,这样就可以触发监听事件,客户端B就会得到通知,同样,客户端B判断自己是否为最小节点,如果是,那么则加锁成功