redis 应用-分布式锁
单体应用可以使用 synchronized 或 RentranLock 来加锁,synchronized 推荐使用类锁,也就是字节码锁,这样保证是全局唯一的,如果使用对象锁,要根据业务确定这个对象锁在这个业务中是唯一的。
对于微服务架构下,单体应用锁就不合适了,每个服务多个节点部署,虚拟机都不是用一个,肯定保证不了唯一性。比如同一个商品下单,用户 a 的请求到 节点1 处理,用户 b 的请求到 节点2 处理。
分布式锁
所有节点的所有线程都到同一个地方去获取锁,只有一个线程能成功获取,未获取到锁的线程就等待或结束。具备以下条件
- 互斥性:任意时刻只能一个客户端获取到锁
- 锁超时释放:某个客户端超时持有锁,需要自动释放机制。简言之就是 防止死锁
- 安全性:只能当前持有者释放锁
实现方式有数据库、Zookeeper、redis 等,这里只介绍 redis
redis 分布式锁
基本方式
利用 setnx 命令往 redis 添加值的方式来加锁。setnx key value,当 key 不存在才能设置成功
- 业务开始,先使用 setnx 加锁(如果设置值成功,说明加锁成功,反之加锁失败)
- 当加锁成功,处理业务
- 业务结束,释放锁(删除 key)
以上方式是有隐患的,假设 节点1 加锁成功,但是处理业务出现异常或者节点1直接挂了,导致锁始终存在,发生死锁,别的节点再也不能获取锁了
线程a | 线程b |
---|---|
setnx 加锁成功 | setnx 加锁失败 |
业务处理 | setnx 加锁失败 |
发生异常或节点挂了(这个锁就永不删除) | setnx 加锁失败 |
方案改进,锁自动过期避免死锁
给 setnx 加过期时间。不要单独给 key 增加过期时间(也就是不要写成两条命令,一条 setnx,一条 expire,合在一起才能保证原子性)
# 分开写
setnx key valye;
expire key 时间;
# 合在一起写
setex key 过期时间 value;
对应 redisTemplate 写法
// 60s 自动释放
redisTemplate.opsForValue().setIfAbsent(key, value, 60L, TimeUnit.SECONDS);
这种还是会有隐患,比如过期时间设置的 10s,但是业务需要 20s,这种情况会有问题
- 线程a 的业务没结束锁就释放了(需要延迟释放锁机制,等到业务结束才释放锁)
- 线程b 执行,发现加锁成功,执行线程b的业务,执行的过程中,线程a 业务结束,线程a 释放锁。a 的锁自动释放了,现在释放的是 线程b 的锁
线程a | 线程b |
---|---|
setnx 加锁成功 | setnx 加锁失败 |
业务处理 | setnx 加锁失败 |
发生异常或节点挂了(这个锁就永不删除) | setnx 加锁失败 |
自动过期 | setnx 加锁成功 |
方案再次改进,自己释放自己加的锁
自己释放自己的锁,这个比较好实现,setnx 只添加了 key,value 没有处理,可以把 value 设置为一个 uuid,业务结束时,删除值是 uuid 的 key。
步骤 | 描述 |
---|---|
setnx 加锁 | 如果成功,key 的值设置成一个 uuid |
业务处理 | |
业务结束,释放锁 | 查一下 key,如果 key 的值是上面设置的 uuid 才删除 key 如果能查到 key,但是值不是上面设置的 uuid,现在如果删除,就把别的线程的 key 删除了 |
这个过程分为 3 个步骤 查找 key
,判断 value
,删除 key
,极端情况下还是会有问题,因为这三个操作是独立的的,没有原子性,可能判断完正准备删除还没删除时,刚好到了 key 的过期时间自动删除,这时删除的还是别的线程的锁。极端情况如下:
某个线程 | 锁过期时间 |
---|---|
查找 key | |
判断 key() | |
到了过期时间,自动删除 | |
删除 key |
这时需要保证删除 key 的原子性,利用 redis 的事务或 lua 脚本
方案再次改进,自动续期
当加锁后,开启一个线程,线程的作用也很简单:就是每隔一段时间检查一下 redis 服务器是否存在该 key,如果存在,就把过期时间加长。这样就能避免业务处理时间大于锁过期时间导致的问题。redisson 中就是这种逻辑,这个线程也有个名字叫做 看门狗。redisson 中只有当设置了自动过期时间的 key 才引入 看门狗线程
RedLock
前面讨论的都是单机版 redis 服务器,往往生产环境中 redis 都是多台,哨兵 或 cluster 模式。
可能出现锁丢失,redis master 添加 key,还没有同步到 salve,此时 master 挂了,其中的一个 salve 升级为 master,这时原来 master 中的 key 就丢失了
解决方案就是红锁:大概意思是 master 节点是多个,尽量避免同时挂掉,每个 master 之间不是自动同步的,而是分别写入,超过半数写入成功,才算加锁成功。比如 添加一个 key,往 5 个 master 里都执行 setnx 命令,还有一些时间上的校验等,后面有兴趣再深入吧