834-Redis 分布式锁

Redis 分布式锁

随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于 分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发 控制锁策略失效，单纯的 Java API 并不能提供分布式锁的能力。为了解决这个问题就 需要一种跨 JVM 的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

分布式锁主流的实现方案：

1. 基于数据库实现分布式锁
2. 基于缓存（Redis 等）
3. 基于 Zookeeper

每一种分布式锁解决方案都有各自的优缺点：
性能：redis 最高
可靠性：zookeeper 最高

这里，我们就基于 redis 实现分布式锁。

使用 redis 实现分布式锁

redis:命令

# set sku:1:info “OK” NX PX 10000

EX second ：设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。

PX millisecond ：设置键的过期时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。

NX ：只在键不存在时，才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 。
XX ：只在键已经存在时，才对键进行设置操作。

1. 多个客户端同时获取锁（setnx）
2. 获取成功，执行业务逻辑{从 db 获取数据，放入缓存}，执行完成释放锁（del）
3. 其他客户端等待重试

编写代码

Redis: set num 0


重启，服务集群，通过网关压力测试： ab -n 1000 -c 100 http://192.168.140.1:8080/test/testLock

查看 redis 中 num 的值：

基本实现。
问题：setnx 刚好获取到锁，业务逻辑出现异常，导致锁无法释放
解决：设置过期时间，自动释放锁。

优化之设置锁的过期时间

设置过期时间有两种方式：

1. 首先想到通过 expire 设置过期时间（缺乏原子性：如果在 setnx 和 expire 之 间出现异常，锁也无法释放）
2. 在 set 时指定过期时间（推荐）

设置过期时间：

压力测试肯定也没有问题。
自行测试
问题：可能会释放其他服务器的锁。

场景：如果业务逻辑的执行时间是 7s。执行流程如下

1. index1 业务逻辑没执行完，3 秒后锁被自动释放。
2. index2 获取到锁，执行业务逻辑，3 秒后锁被自动释放。
3. index3 获取到锁，执行业务逻辑
4. index1 业务逻辑执行完成，开始调用 del 释放锁，这时释放的是 index3 的锁， 导致 index3 的业务只执行 1s 就被别人释放。

最终等于没锁的情况。
解决：setnx 获取锁时，设置一个指定的唯一值（例如：uuid）；释放前获取这 个值，判断是否自己的锁

优化之 UUID 防误删

删除操作缺乏原子性

场景：

优化之 LUA 脚本保证删除的原子性

项目中正确使用：

总结

1、加锁

2、使用 lua 释放锁

3、重试

为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：

• 互斥性。在任意时刻，只有一个客户端能持有锁。
• • 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也 能保证后续其他客户端能加锁。
• • 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人 加的锁给解了。
• • 加锁和解锁必须具有原子性