1、单机锁
考虑在并发场景并且存在竞态的状况下，我们就要实现同步机制了，最简单的同步机制就是加锁。
加锁可以帮我们锁住资源，如内存中的变量，或者锁住临界区(线程中的一段代码)，使得同一个时刻只有一个线程能访问某一个区域。
如果是单实例(单进程部署)，那么单机锁就可以满足我们的要求了，如synchronized，ReentrantLock。
因为在一个进程中的不同线程可以共享这个锁。
2、分布式锁
但是如果场景来到了分布式系统呢？
分布式系统部署在不同的机器上，或者只是简单的多进程部署。这样各个进程之间无法共享同一个锁。
这时候我们要加分布式锁。
分布式锁大概就是这么一个东西：通过共享的存储缓存一个状态值，用状态值的变化标识锁的占用和释放。
可以通过mysql，redis，zk等实现分布式锁，这里我们实现一个redis的。如果你用java其实使用zk会很简单。
3、为什么redis能用来实现分布式锁？
1）Redis是单进程单线程模式
redis实现为单进程单线程模式，这样多个客户端并不存在竞态关系。
2）原子性原语
redis提供了可以实现原子操作的原语如setnx、getset等。
setnx
1）SETNX key value
将 key 的值设为 value ，当且仅当 key 不存在。
若给定的 key 已经存在，则 SETNX 不做任何动作。
SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。
可用版本：
>= 1.0.0
时间复杂度：
O(1)
返回值：
设置成功，返回 1 。
设置失败，返回 0 。复制
getset
GETSET key value
将给定 key 的值设为 value ，并返回 key 的旧值(old value)。
当 key 存在但不是字符串类型时，返回一个错误。
可用版本：
>= 1.0.0
时间复杂度：
O(1)
返回值：
返回给定 key 的旧值。
当 key 没有旧值时，也即是， key 不存在时，返回 nil 。
复制
4、实现
package com.xiaoju.dqa.fusor.utils;
import com.xiaoju.dqa.fusor.client.RedisClient;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
@Component
public class DistributeLockUtil {
// 锁超时时间, 防止死锁
private static final long LOCK_TIMEOUT = 60;
@Autowired
private RedisClient redisClient;
private boolean locked = false;
public boolean lock(String key) {
String expireTime = String.valueOf(System.currentTimeMillis() + LOCK_TIMEOUT * 1000);
/*
* setnx 返回1
* 说明: 1)key不存在, 2)成功写入锁, 并更新锁的生存时间
* 也就是get锁
* */
if (redisClient.setnx(key, expireTime) == 1) {
locked = true;
return true;
}
/*
* 没有get锁, 下面进入判断锁超时逻辑
* */
String currentExpireTime = redisClient.get(key);
/*
* 锁生存时间已经过了, 说明锁已经超时
* */
if (Long.parseLong(currentExpireTime) < System.currentTimeMillis()) {
String oldValueStr = redisClient.getSet(key, expireTime);
/*
* 判断锁生存时间和你改的写那个时间是否相等
* 相当于你竞争了一个更新锁
* */
if (oldValueStr.equals(currentExpireTime)) {
locked = true;
return true;
}
}
return false;
}
public void release(String key) {
if (locked) {
redisClient.del(key);
locked = false;
}
}
}复制
5、死锁
为了解决死锁，这里设置了锁的超时时间。
private static final long LOCK_TIMEOUT = 60;复制
并通过setnx时更新锁生存时间来维护锁超时的判定。
String expireTime = String.valueOf(System.currentTimeMillis() + LOCK_TIMEOUT * 1000);
...
if (redisClient.setnx(key, expireTime) == 1) {
...
}
...
String oldValueStr = redisClient.getSet(key, expireTime);
...复制
为什么要使用这种方式，而不是expire呢？
因为setnx和expire不能作为一个原子性的操作存在，设想如果setnx之后，在执行expire之前出现了异常，那么锁将没有超时时间。也就是死锁。
6、解决锁超时引入的竞态
设想三个客户端，C0,C1,C2
如果C0持有锁并且崩溃，锁没有释放。
C1和C2同时发现了锁超时。
然后都通过getset去拿到了旧值，在对比了旧值和之前值之后，如果相等，那么说明“我”成功修改了旧值，那么我就拿到了锁。
7、 时钟同步
我们看到foo.lock的value值为时间戳，所以要在多客户端情况下，保证锁有效，一定要同步各服务器的时间，如果各服务器间，时间有差异。时间不一致的客户端，在判断锁超时，就会出现偏差，从而产生竞争条件。 锁的超时与否，严格依赖时间戳，时间戳本身也是有精度限制，假如我们的时间精度为秒，从加锁到执行操作再到解锁，一般操作肯定都能在一秒内完成。这样的话，我们上面的CASE，就很容易出现。所以，最好把时间精度提升到毫秒级。这样的话，可以保证毫秒级别的锁是安全的。
8、一些处理不了的情况
设想三个客户端，C0,C1,C2
如果C0持有锁很长，锁已经超时。这时候有C1,C2判断锁超时了，然后通过超时竞争，C1拿到了锁。
这时C0醒了过来，删除了C1的锁。
这时，C1认为自己独占了锁，其他的进程也进入了竞争锁的情况
对于这种情况，这里是没有提供解决办法的。文章来源：https://www.toymoban.com/news/detail-518333.html
思路是：你降级你的锁，比如给你的锁加上uuid，对不同的业务或者不同的session加上对应粒度的锁。文章来源地址https://www.toymoban.com/news/detail-518333.html
到了这里，关于分布式锁的实现(redis)的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
