目录1. 什么是分布式锁2. 分布式锁该具备的特性3. 基于数据库做分布式锁4. 基于Redis做分布式锁4.1 超时问题4.2 可重入锁4.3 集群环境的缺陷4.4 Redlock
目前很多大型网站及应用都是分布式部署的,分布式场景中的数据一致性问题一直是一个比较重要的话题。
基于 CAP理论,任何一个分布式系统都无法同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance),最多只能同时满足两项。
我们为了保证数据的最终一致性,需要很多的技术方案来支持,比如分布式事务、分布式锁等。通常大家都会采redis做分布式锁,但这样就可以高枕无忧了吗?
分布式与单机情况下最大的不同在于其不是多线程而是多进程,而数据只有一份(或有限制),也就是说单机的共享内存已解决不了一致性写问题,此时需要利用锁的技术控制某一时刻修改数据的进程数。
当在分布式模型下,分布式锁还是可以将标记存在内存,只是该内存不是某个进程分配的内存而是公共内存(Redis、Memcache)。至于利用数据库、文件等做锁与单机的实现是一样的,只要保证标记能互斥就行。
如果按分布式该具备的特性来逐条匹配,特别是高可用(存在单点)、高性能是硬伤
一般都使用 setnx(set if not exists) 指令,只允许被一个客户端占有,先来先得, 用完后再通过 del 指令释放。
如果中间逻辑执行时发生异常,可能会导致 del 指令没有被执行,这样就会陷入死锁,怎么破?
对,给锁加个过期时间(即使出现异常也可以保证几秒之后锁会自动释放)!
但setnx 和 expire 之间redis服务器突然挂掉,怎么破?
其实该问题的根源就在于 setnx 和 expire 是两条指令而不是原子指令。为了解决这个疑难,Redis 开源社区涌现了一堆分布式锁的 解决方案。为了治理这个乱象,Redis 2.8 版本中加入了 set 指令的扩展参数,使得 setnx 和 expire 指令可以一起执行,彻底解决了分布式锁的乱象。
总之,setnx 和 expire 组合就是分布式锁的奥义所在。
如果在加锁和释放锁之间的逻辑执行的太长,超出了超时限制,怎么破?
也就是说第一个线程持有的锁过期了但临界区的逻辑还没有执行完,这个时候第二个线程就提前重新持有了这把锁,导致每个请求执行临界区代码时不能严格的串行执行。
Redis 的分布式锁不能解决超时问题,建议分布式锁不要用于较长时间的任务。
稍微安全一点的方案是为 set 指令的 value 参数设置为一个随机数,释放锁时先匹配随机数是否一致,一致的话再删除 key,这是可以确保当前线程占有的锁不会被其它线程释放,但是并不能解决锁被redis服务器自动释放的。
int tag = random.nextint()//随机数
boolean nx=true;
int ex=5;
if(redis.set(key, tag, nx, ex)){
do_something()
redis.delifequals(key, tag)//不存在这样的命令
}
但是匹配 value 和删除 key 不是一个原子操作,怎么破?
需要使用 lua 脚本来处理了,因为 Lua 脚本可以保证连续多个指令的原子性执行。
#delifequals.lua文件,下面的是社区热门代码
if redis.call('get', KEYS[1]) == ARGV[1] then
return redis.call('del', KEYS[1])
else
return 0
end
//java调用
public void delifequals(){
String script = readScript("delifequals.lua");
int tag = 5;
String key = "key";
Object eval = jedis.eval(script, Lists.newArrayList(key), Lists.newArrayList(tag));
System.out.println(eval);
}
redis有类似Java 语言里有个 ReentrantLock 就是可重入锁吗?
要支持可重入,需要对jedis 的 set 方法进行包装,思路是:使用 Threadlocal 存储当前持有锁的计数。可重入锁加重了客户端的复杂性,精确一点还需要考虑内存锁计数的过期时间,代码复杂度将会继续升高。
public class JedisWithReentrantLock {
private Jedis jedis;
private ThreadLocal<Map<String, Integer>> lockers = new ThreadLocal<>();
public JedisWithReentrantLock(Jedis jedis) {
this.jedis = jedis;
}
private boolean set(String key) {
return jedis.set(key, "", "nx", "ex", 5L) != null;
}
private void del(String key) {
jedis.del(key);
}
private Map<String, Integer> getLockers() {
Map<String, Integer> refs = lockers.get();
if (refs != null) {
return refs;
}
lockers.set(Maps.newHashMap());
return lockers.get();
}
public boolean lock(String key) {
Map<String, Integer> refs = getLockers();
Integer refCount = refs.get(key);
if (refCount != null) {
refs.put(key, refCount + 1);
return true;
}
if (!this.set(key)) {
return false;
}
refs.put(key, 1);
return true;
}
public boolean unlock(String key) {
Map<String, Integer> refs = getLockers();
Integer refCount = refs.get(key);
if (refCount == null) {
return false;
}
refCount -= 1;
if (refCount > 0) {
refs.put(key, refCount);
} else {
refs.remove(key);
this.del(key);
}
return true;
}
}
@Test
public void runJedisWithReentrantLock() {
JedisWithReentrantLock redis = new JedisWithReentrantLock(jedis);
System.out.println(redis.lock("alex"));
System.out.println(redis.lock("alex"));
System.out.println(redis.unlock("alex"));
System.out.println(redis.unlock("alex"));
}
在集群环境下,这种方式是有缺陷的(数据不一致的情况)。比如在 Sentinel 集群中,主节点挂掉时(原先第一个客户端在主节点中申请成功了一把锁),从节点A 会取而代之并晋升为主(但是这把锁还没有来得及同步),虽然客户端上却并没有明显感知,但是这时另一个客户端过来请求 从节点A 可以成功加锁,这样就会导致系统中同样一把锁被两个客户端同时持有。
主从发生故障转移,一般持续时间极短,数据不一致的情况基本上都是小概率事件。
上面的集群同步问题导致的缺陷,难道就没有解决方案吗?
为此Antirez 发明了 Redlock 算法,它的流程比较复杂,不过已经有了很多开源的实现。
原理
使用 Redlock,需要提供多个 Redis 实例,这些实例之前相互独立没有主从关系。同很多分布式算法一样,redlock 也使用少数服从多数。
加锁时,它会向过半节点发送 set(key, value, nx, ex) 指令,只要过半节点 set 成功,那就认为加锁成功。释放锁时,需要向所有节点发送 del 指令。缺陷:因为 Redlock 需要向多个节点进行读写,意味着相比单实例 Redis 性能会下降一些。
注:Redlock算法还需要考虑出错重试、时钟漂移等很多细节问题
使用场景
如果你很在乎高可用性,希望挂了一台 redis 完全不受影响,那就应该考虑 redlock。
引用资料
How to do distributed locking
Redlock的实现
以上为个人经验,希望能给大家一个参考,也希望大家多多支持编程网。
--结束END--
本文标题: 带你轻松掌握Redis分布式锁
本文链接: https://lsjlt.com/news/156815.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-03-01
2024-03-01
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0