分布式锁
2022-05-08 17:05:00 1 举报AI智能生成
分布式锁
作者其他创作
大纲/内容
概述
系统是分布式部署的，日常开发中，秒杀下单、抢购商品 等等业务场景，为了防⽌库存超卖，都需要用到分布式锁
实现方式
基于数据库实现的分布式锁
悲观锁
可以使用select ... for update 来实现分布式锁。我们自己的项目，分布式定时任务 ，
就使用类似的实现方案
MySQL设置innodb_lock_wait_timeout超时时间
就使用类似的实现方案
MySQL设置innodb_lock_wait_timeout超时时间
乐观锁
乐观锁，顾名思义，就是很乐观，每次更新操作，都觉得不会存在并发冲突，只有更新失败后，才重试。它是基于CAS思想实现的
基于Redis实现的分布式锁
setnx + expire
setnx + value值是过期时间
set的扩展命令（set ex px nx）
set ex px nx + 校验唯一随机值,再删除
Redisson
Redisson + RedLock
setnx + value值是过期时间
set的扩展命令（set ex px nx）
set ex px nx + 校验唯一随机值,再删除
Redisson
Redisson + RedLock
setnx + expire
if（jedis.setnx(key,lock_value) == 1）{ //setnx加锁
//走在这里redis断了lock就永远锁住了
expire（key，100）; //设置过期时间
try {
do something //业务处理
}catch(){
}
finally {
jedis.del(key); //释放锁
}
}
//走在这里redis断了lock就永远锁住了
expire（key，100）; //设置过期时间
try {
do something //业务处理
}catch(){
}
finally {
jedis.del(key); //释放锁
}
}
这段代码是可以加锁成功，但是你有没有发现问题，加锁操作和设置超时时间是分开的 。假设在执行完setnx加锁后，正要执行expire设置过期时间时，进程crash掉或者要重启维护了，那这个锁就长生不老 了，别的线程永远获取不到锁啦，所以分布式锁不能这么实现 ！
setnx + value值是过期时间
long expires = System.currentTimeMillis() + expireTime; //系统时间+设置的过期时间
String expiresStr = String.valueOf(expires);
// 如果当前锁不存在，返回加锁成功
if (jedis.setnx(key, expiresStr) == 1) {
return true;
}
// 如果锁已经存在，获取锁的过期时间
String currentValueStr = jedis.get(key);
// 如果获取到的过期时间，小于系统当前时间，表示已经过期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
// 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间（不了解redis的getSet命令的小伙伴，可以去官网看下哈）
String oldValueStr = jedis.getSet(key, expiresStr);
if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
// 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才可以加锁
return true;
}
}
//其他情况，均返回加锁失败
return false;
}
String expiresStr = String.valueOf(expires);
// 如果当前锁不存在，返回加锁成功
if (jedis.setnx(key, expiresStr) == 1) {
return true;
}
// 如果锁已经存在，获取锁的过期时间
String currentValueStr = jedis.get(key);
// 如果获取到的过期时间，小于系统当前时间，表示已经过期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
// 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间（不了解redis的getSet命令的小伙伴，可以去官网看下哈）
String oldValueStr = jedis.getSet(key, expiresStr);
if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
// 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才可以加锁
return true;
}
}
//其他情况，均返回加锁失败
return false;
}
缺点
1过期时间是客户端自己生成的，分布式环境下，每个客户端的时间必须同步。
2没有保存持有者的唯一标识，可能被别的客户端释放/解锁 。
3锁过期的时候，并发多个客户端同时请求过来，都执行了jedis.getSet()，最终只能有一个客户端加锁成功，但是该客户端锁的过期时间，可能被别的客户端覆盖。
set的扩展命令(set ex px nx)
SET key value [EX seconds] [PX milliseconds] [NX|XX]
if（jedis.set(key, lock_value, "NX", "EX", 100s) == 1）{ //加锁
try {
do something //业务处理
}catch(){
}
finally {
jedis.del(key); //释放锁
}
}
try {
do something //业务处理
}catch(){
}
finally {
jedis.del(key); //释放锁
}
}
这个方案可能存在这样的问题：
锁过期释放了，业务还没执行完。
锁被别的线程误删
锁被别的线程误删
假设线程A和B，都想用key加锁，最后A抢到锁加锁成功，但是由于执行业务逻辑的耗时很长，超过了设置的超时时间100s。这时候，Redis就自动释放了key锁。这时候线程B就可以加锁成功了，接下啦，它也执行业务逻辑处理。假设碰巧这时候，A执行完自己的业务逻辑，它就去释放锁，但是它就把B的锁给释放了。
set ex px nx + 校验唯一随机值,再删除
if（jedis.set(key, uni_request_id, "NX", "EX", 100s) == 1）{ //加锁
try {
do something //业务处理
}catch(){
}
finally {
//判断是不是当前线程加的锁,是才释放
if (uni_request_id.equals(jedis.get(key))) {
//这里如果代码刚好超时就别的线程刚好获取锁就把别的线程给删了
jedis.del(key); //释放锁
}
}
}
try {
do something //业务处理
}catch(){
}
finally {
//判断是不是当前线程加的锁,是才释放
if (uni_request_id.equals(jedis.get(key))) {
//这里如果代码刚好超时就别的线程刚好获取锁就把别的线程给删了
jedis.del(key); //释放锁
}
}
}
在这里，判断当前线程加的锁和释放锁不是一个原子操作 。如果调用jedis.del()释放锁的时候，可能这把锁已经不属于当前客户端 ，会解除他人加的锁。
一般可以用lua脚本包装一下
if redis.call('get',KEYS[1]) == ARGV[1] then
return redis.call('del',KEYS[1])
else
return 0
end;
return redis.call('del',KEYS[1])
else
return 0
end;
缺点：锁过期释放了，业务还没执行完的问题 。
Redisson
对于可能存在锁过期释放，业务没执行完 的问题。我们可以稍微把锁过期时间设置长一些，大于正常业务处理时间就好啦。如果你觉得不是很稳，还可以给获得锁的线程，开启一个定时守护线程，每隔一段时间检查锁是否还存在，存在则对锁的过期时间延长，防止锁过期提前释放
redisson解决问题的思路
只要线程一加锁成功，就会启动一个watch dog看门狗，它是一个后台线程，
会每隔10秒（默认过期时间是30秒过期）检查一下，如果线程1还持有锁，那么就会不断的延长锁key的生存时间。
因此，Redisson就是使用watch dog解决了锁过期释放，业务没执行完问题 。
会每隔10秒（默认过期时间是30秒过期）检查一下，如果线程1还持有锁，那么就会不断的延长锁key的生存时间。
因此，Redisson就是使用watch dog解决了锁过期释放，业务没执行完问题 。
缺点：
1如果是分布式redis master挂了slave还没同步到数据编程了master那么就会出现两个线程
获得锁的情况.可以通过min-slaves-to-write=1但是影响了redis的可用性和高性能
获得锁的情况.可以通过min-slaves-to-write=1但是影响了redis的可用性和高性能
Redisson + RedLock
Redlock 。它的核心思想是这样的：部署多个Redis master，以保证它们不会同时宕掉。并且这些master节点是完全相互独立的，相互之间不存在数据同步。同时，需要确保在这多个master实例上，是与在Redis单实例，使用相同方法来获取和释放锁
我们假设当前有5个Redis master节点，在5台服务器上面运行这些Redis实例。
RedLock的实现步骤
获取当前时间，以毫秒为单位。
按顺序向5个master节点请求加锁。客户端设置网络连接和响应超时时间，并且超时时间要小于锁的失效时间。（假设锁自动失效时间为10秒，则超时时间一般在5-50毫秒之间,我们就假设超时时间是50ms吧）。如果超时，跳过该master节点，尽快去尝试下一个master节点。
客户端使用当前时间减去开始获取锁时间（即步骤1记录的时间），得到获取锁使用的时间。当且仅当超过一半（N/2+1，这里是5/2+1=3个节点）的Redis master节点都获得锁，并且使用的时间小于锁失效时间时，锁才算获取成功。（如上图，10s> 30ms+40ms+50ms+4m0s+50ms）
如果取到了锁，key的真正有效时间就变啦，需要减去获取锁所使用的时间。
如果获取锁失败（没有在至少N/2+1个master实例取到锁，有或者获取锁时间已经超过了有效时间），客户端要在所有的master节点上解锁（即便有些master节点根本就没有加锁成功，也需要解锁，以防止有些漏网之鱼）。
按顺序向5个master节点请求加锁。客户端设置网络连接和响应超时时间，并且超时时间要小于锁的失效时间。（假设锁自动失效时间为10秒，则超时时间一般在5-50毫秒之间,我们就假设超时时间是50ms吧）。如果超时，跳过该master节点，尽快去尝试下一个master节点。
客户端使用当前时间减去开始获取锁时间（即步骤1记录的时间），得到获取锁使用的时间。当且仅当超过一半（N/2+1，这里是5/2+1=3个节点）的Redis master节点都获得锁，并且使用的时间小于锁失效时间时，锁才算获取成功。（如上图，10s> 30ms+40ms+50ms+4m0s+50ms）
如果取到了锁，key的真正有效时间就变啦，需要减去获取锁所使用的时间。
如果获取锁失败（没有在至少N/2+1个master实例取到锁，有或者获取锁时间已经超过了有效时间），客户端要在所有的master节点上解锁（即便有些master节点根本就没有加锁成功，也需要解锁，以防止有些漏网之鱼）。
简化下步骤就是：
按顺序向5个master节点请求加锁
根据设置的超时时间来判断，是不是要跳过该master节点。
如果大于等于3个节点加锁成功，并且使用的时间小于锁的有效期，即可认定加锁成功啦。
如果获取锁失败，解锁！
根据设置的超时时间来判断，是不是要跳过该master节点。
如果大于等于3个节点加锁成功，并且使用的时间小于锁的有效期，即可认定加锁成功啦。
如果获取锁失败，解锁！
缺点：
1分布式锁这样处理必然有性能问题，因为要操作多个redis获取多个锁
2回滚问题，获取锁失败必然要回滚之前的数据
3先拆分在聚合的思想与redis的高可用相冲突
2回滚问题，获取锁失败必然要回滚之前的数据
3先拆分在聚合的思想与redis的高可用相冲突
基于Zookeeper实现的分布式锁
Zookeeper的节点Znode有四种类型：
持久节点 ：默认的节点类型。创建节点的客户端与zookeeper断开连接后，该节点依旧存在。
持久节点顺序节点 ：所谓顺序节点，就是在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号，持久节点顺序节点就是有顺序的持久节点。
临时节点 ：和持久节点相反，当创建节点的客户端与zookeeper断开连接后，临时节点会被删除。
临时顺序节点 ：有顺序的临时节点。
Zookeeper分布式锁实现应用了临时顺序节点
zk获取锁过程
当第一个客户端请求过来时，Zookeeper客户端会创建一个持久节点locks。如果它（Client1）想获得锁，需要在locks节点下创建一个顺序节点lock1.如图
接着，客户端Client1会查找locks下面的所有临时顺序子节点，判断自己的节点lock1是不是排序最小的那一个，如果是，则成功获得锁。
这时候如果又来一个客户端client2前来尝试获得锁，它会在locks下再创建一个临时节点lock2
客户端client2一样也会查找locks下面的所有临时顺序子节点，判断自己的节点lock2是不是最小的，此时，发现lock1才是最小的，于是获取锁失败。获取锁失败，它是不会甘心的，client2向它排序靠前的节点lock1注册Watcher事件，用来监听lock1是否存在，也就是说client2抢锁失败进入等待状态。
此时，如果再来一个客户端Client3来尝试获取锁，它会在locks下再创建一个临时节点lock3
同样的，client3一样也会查找locks下面的所有临时顺序子节点，判断自己的节点lock3是不是最小的，发现自己不是最小的，就获取锁失败。它也是不会甘心的，它会向在它前面的节点lock2注册Watcher事件，以监听lock2节点是否存在。
释放锁
我们再来看看释放锁的流程，Zookeeper的客户端业务完成或者发生故障，都会删除临时节点，释放锁。如果是任务完成，Client1会显式调用删除lock1的指令
如果是客户端故障了，根据临时节点得特性，lock1是会自动删除的
lock1节点被删除后，Client2可开心了，因为它一直监听着lock1。lock1节点删除，Client2立刻收到通知，也会查找locks下面的所有临时顺序子节点，发下lock2是最小，就获得锁。
同理，Client2获得锁之后，Client3也对它虎视眈眈
Zookeeper设计定位就是分布式协调，简单易用。如果获取不到锁，只需添加一个监听器即可，很适合做分布式锁。
Zookeeper作为分布式锁也有缺点：如果有很多的客户端频繁的申请加锁、释放锁，对于Zookeeper集群的压力会比较大。
Zookeeper作为分布式锁也有缺点：如果有很多的客户端频繁的申请加锁、释放锁，对于Zookeeper集群的压力会比较大。
. 三种分布式锁对比
数据库分布式锁实现
优点：
简单，使用方便，不需要引入Redis、zookeeper等中间件。
缺点：
不适合高并发的场景
db操作性能较差；
简单，使用方便，不需要引入Redis、zookeeper等中间件。
缺点：
不适合高并发的场景
db操作性能较差；
Redis分布式锁实
优点：
性能好，适合高并发场景
较轻量级
有较好的框架支持，如Redisson
缺点：
aof rdb的存储方式可能会丢数据
过期时间不好控制
需要考虑锁被别的线程误删场景
性能好，适合高并发场景
较轻量级
有较好的框架支持，如Redisson
缺点：
aof rdb的存储方式可能会丢数据
过期时间不好控制
需要考虑锁被别的线程误删场景
Zookeeper分布式锁实现
缺点：
性能不如redis实现的分布式锁
比较重的分布式锁。
优点：
有较好的性能和可靠性
有封装较好的框架，如Curator
性能不如redis实现的分布式锁
比较重的分布式锁。
优点：
有较好的性能和可靠性
有封装较好的框架，如Curator
对比汇总
从性能角度（从高到低）Redis > Zookeeper >= 数据库；
从理解的难易程度角度（从低到高）数据库 > Redis > Zookeeper；
从实现的复杂性角度（从低到高）Zookeeper > Redis > 数据库；
从可靠性角度（从高到低）Zookeeper > Redis > 数据库。
从理解的难易程度角度（从低到高）数据库 > Redis > Zookeeper；
从实现的复杂性角度（从低到高）Zookeeper > Redis > 数据库；
从可靠性角度（从高到低）Zookeeper > Redis > 数据库。
0 条评论
下一页
