在公司的项目中用到了分布式锁,但只会用却不明白其中的规则
所以写一篇文章来记录
使用场景:交易服务,使用redis分布式锁,防止重复提交订单,出现超卖问题
分布式锁应该具备哪些条件
- 在分布式系统环境下,一个方法在同一时间只能被一个机器的一个线程执行
- 高可用的获取锁与释放锁
- 高性能的获取锁与释放锁
- 具备可重入特性(可理解为重新进入,由多于一个任务并发使用,而不必担心数据错误)
- 具备锁失效机制,防止死锁
- 具备非阻塞锁特性,即没有获取到锁将直接返回获取锁失败
分布式锁的实现方式
- 基于数据库乐观锁/悲观锁
- Redis分布式锁(本文):利用
setnx
命令。此命令是原子性操作,只有key不存在的情况下,才能set
,就意味着线程获取到了锁 - Zookeeper分布式锁:利用 Zookeeper 的顺序临时节点,来实现分布式锁和等待队列。Zookeeper 设计的初衷,就是为了实现分布式锁服务的
- Memcached:利用
add
命令。此命令是原子性操作,只有key不存在的情况下,才能add
,也就意味着线程获取到了锁
redis是如何实现加锁的?
在redis中,有一条命令,实现锁
1 | bash复制代码SETNX key value |
该命令的作用是将 key
的值设为 value
,当且仅当 key
不存在。若给定的 key
已经存在,则 SETNX 不做任何动作。设置成功,返回 1
;设置失败,返回 0
使用 redis 来实现锁的逻辑就是这样的
1 | bash复制代码线程 1 获取锁 -- > setnx lockKey lockvalue |
接下来我们将基于springboot实现redis分布式锁
1. 引入redis
、springmvc、lombok
依赖
1 | java复制代码<?xml version="1.0" encoding="UTF-8"?> |
2. 新建RedisDistributedLock.java并书写加锁解锁逻辑
1 | java复制代码import lombok.extern.slf4j.Slf4j; |
补充:
1. spring-data-redis
有StringRedisTempla
和RedisTemplate
两种,但是我选择了RedisTemplate
,因为他比较万能。他们的区别是:当你的redis数据库里面本来存的是字符串数据或者你要存取的数据就是字符串类型数据的时候,那么你就使用StringRedisTemplate即可, 但是如果你的数据是复杂的对象类型,而取出的时候又不想做任何的数据转换,直接从Redis里面取出一个对象,那么使用RedisTemplate是 更好的选择。
2. 选择lua脚本是因为,脚本运行是原子性的,在脚本运行期间没有客户端可以操作,所以在释放锁的时候用了lua脚本,
而redis最新版加锁时保证了Redis值和自动过期时间的原子性,所用没用lua脚本
3. 创建测试类 TestController
1 | java复制代码import lombok.extern.slf4j.Slf4j; |
4. 使用postman进行测试
5. redis分布式锁的缺点
上面我们说的是redis,是单点的情况。如果是在redis sentinel集群中情况就有所不同了。在redis sentinel集群中,我们具有多台redis,他们之间有着主从的关系,例如一主二从。我们的set命令对应的数据写到主库,然后同步到从库。当我们申请一个锁的时候,对应就是一条命令
setnx mykey myvalue
,在redis sentinel集群中,这条命令先是落到了主库。假设这时主库down了,而这条数据还没来得及同步到从库,sentinel将从库中的一台选举为主库了。这时,我们的新主库中并没有mykey这条数据,若此时另外一个client执行setnx mykey hisvalue
, 也会成功,即也能得到锁。这就意味着,此时有两个client获得了锁。这不是我们希望看到的,虽然这个情况发生的记录很小,只会在主从failover的时候才会发生,大多数情况下、大多数系统都可以容忍,但是不是所有的系统都能容忍这种瑕疵。
6.redis分布式锁的优化
为了解决故障转移情况下的缺陷,Antirez 发明了 Redlock 算法,使用redlock算法,需要多个redis实例,加锁的时候,它会想多半节点发送
setex mykey myvalue
命令,只要过半节点成功了,那么就算加锁成功了。释放锁的时候需要想所有节点发送del命令。这是一种基于【大多数都同意】的一种机制。感兴趣的可以查询相关资料。在实际工作中使用的时候,我们可以选择已有的开源实现,python有redlock-py,java 中有Redisson redlock。redlock确实解决了上面所说的“不靠谱的情况”。但是,它解决问题的同时,也带来了代价。你需要多个redis实例,你需要引入新的库 代码也得调整,性能上也会有损。所以,果然是不存在“完美的解决方案”,我们更需要的是能够根据实际的情况和条件把问题解决了就好。
至此,我大致讲清楚了redis分布式锁方面的问题(日后如果有新的领悟就继续更新)。
** 分布式锁对比**
数据库分布式锁实现
缺点:
- db操作性能较差,并且有锁表的风险
- 非阻塞操作失败后,需要轮询,占用cpu资源
- 长时间不commit或者长时间轮询,可能会占用较多连接资源
Redis分布式锁实现
缺点:
- 锁删除失败 过期时间不好控制
- 非阻塞,操作失败后,需要轮询,占用cpu资源
ZK分布式锁实现
缺点:
- 性能不如redis实现,主要原因是写操作(获取锁释放锁)都需要在Leader上执行,然后同步到follower。
总结
从理解的难易程度角度(从低到高)数据库 > Redis >Zookeeper
从实现的复杂性角度(从低到高)Zookeeper >= Redis > 数据库
从性能角度(从高到低)缓存 > Zookeeper >= 数据库
从可靠性角度(从高到低)Zookeeper > Redis > 数据库
本文转载自: 掘金