Redis分布式锁的五大演进攻略

1）前端将 10W 的高并发请求转发给四个题目微服务。

5）未获取到的线程需要等待锁释放。

6）释放锁后，其他线程抢占锁。

7）重复执行步骤 4、5、6。

set   NX

docker exec -it  redis-cli

set wukong 1111 NX

• 多个并发线程都去 Redis 中申请锁，也就是执行 setnx 命令，假设线程 A 执行成功，说明当前线程 A 获得了。

• 其他线程执行 setnx 命令都会是失败的，所以需要等待线程 A 释放锁。

• 线程 A 执行完自己的业务后，删除锁。

• 其他线程继续抢占锁，也就是执行 setnx 命令。因为线程 A 已经删除了锁，所以又有其他线程可以抢占到锁了。

// 1.先抢占锁Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "123");if(lock) {  // 2.抢占成功，执行业务  List typeEntityListFromDb = getDataFromDB();  // 3.解锁  redisTemplate.delete("lock");  return typeEntityListFromDb;} else {  // 4.休眠一段时间  sleep(100);  // 5.抢占失败，等待锁释放  return getTypeEntityListByRedisDistributedLock();}

// 在 10s 以后，自动清理 lockredisTemplate.expire("lock", 10, TimeUnit.SECONDS);

// 1.先抢占锁Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "123");if(lock) {    // 2.在 10s 以后，自动清理 lock    redisTemplate.expire("lock", 10, TimeUnit.SECONDS);    // 3.抢占成功，执行业务    List typeEntityListFromDb = getDataFromDB();    // 4.解锁    redisTemplate.delete("lock");    return typeEntityListFromDb;}

# 设置某个 key 的值并设置多少毫秒或秒 过期。set   PX  NX或set   EX  NX

ttl 

# 设置 key=wukong，value=1111，过期时间=5000msset wukong 1111 PX 5000 NX# 查看 key 的状态ttl wukong

setIfAbsent("lock", "123", 10, TimeUnit.SECONDS);

• 用户 A 先抢占到了锁，并设置了这个锁 10 秒以后自动开锁，锁的编号为 123。

• 10 秒以后，A 还在执行任务，此时锁被自动打开了。

• 用户 B 看到房间的锁打开了，于是抢占到了锁，设置锁的编号为 123，并设置了过期时间 10 秒。

• 因房间内只允许一个用户执行任务，所以用户 A 和 用户 B 执行任务产生了冲突。

• 用户 A 在 15 s 后，完成了任务，此时 用户 B 还在执行任务。

• 用户 A 主动打开了编号为 123的锁。

• 用户 B 还在执行任务，发现锁已经被打开了。

• 用户 B 非常生气：我还没执行完任务呢，锁怎么开了？

• 用户 B 的锁被 A 主动打开后，A 离开房间，B 还在执行任务。

• 用户 C 抢占到锁，C 开始执行任务。

• 因房间内只允许一个用户执行任务，所以用户 B 和 用户 C 执行任务产生了冲突。

• 设置锁的过期时间时，还需要设置唯一编号。

• 主动删除锁的时候，需要判断锁的编号是否和设置的一致，如果一致，则认为是自己设置的锁，可以进行主动删除。

// 1.生成唯一 idString uuid = UUID.randomUUID().toString();// 2. 抢占锁Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", uuid, 10, TimeUnit.SECONDS);if(lock) {    System.out.println("抢占成功：" + uuid);    // 3.抢占成功，执行业务    List typeEntityListFromDb = getDataFromDB();    // 4.获取当前锁的值    String lockValue = redisTemplate.opsForValue().get("lock");    // 5.如果锁的值和设置的值相等，则清理自己的锁    if(uuid.equals(lockValue)) {        System.out.println("清理锁：" + lockValue);        redisTemplate.delete("lock");    }    return typeEntityListFromDb;} else {    System.out.println("抢占失败，等待锁释放");    // 4.休眠一段时间    sleep(100);    // 5.抢占失败，等待锁释放    return getTypeEntityListByRedisDistributedLock();}

• 生成随机唯一 id，给锁加上唯一值。

• 抢占锁，并设置过期时间为 10 s，且锁具有随机唯一 id。

• 抢占成功，执行业务。

• 执行完业务后，获取当前锁的值。

• 如果锁的值和设置的值相等，则清理自己的锁。

• 时刻：0s。线程 A 抢占到了锁。

• 时刻：9.5s。线程 A 向 Redis 查询当前 key 的值。

• 时刻：10s。锁自动过期。

• 时刻：11s。线程 B 抢占到锁。

• 时刻：12s。线程 A 在查询途中耗时长，终于拿多锁的值。

• 时刻：13s。线程 A 还是拿自己设置的锁的值和返回的值进行比较，值是相等的，清理锁，但是这个锁其实是线程 B 抢占的锁。

if redis.call("get",KEYS[1]) == ARGV[1]then    return redis.call("del",KEYS[1])else    return 0end

// 脚本解锁String script = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";redisTemplate.execute(new DefaultRedisScript(script, Long.class), Arrays.asList("lock"), uuid);

• 缺陷：业务代码出现异常或者服务器宕机，没有执行主动删除锁的逻辑，就造成了死锁。

• 改进：设置锁的自动过期时间，过一段时间后，自动删除锁，这样其他线程就能获取到锁了。

• 缺陷：占锁和设置锁过期时间是分步两步执行的，不是原子操作。

• 改进：占锁和设置锁过期时间保证原子操作。

• 缺陷：主动删除锁时，因锁的值都是相同的，将其他客户端占用的锁删除了。

• 改进：每次占用的锁，随机设为较大的值，主动删除锁时，比较锁的值和自己设置的值是否相等。

• 缺陷：获取锁、比较锁的值、删除锁，这三步是非原子性的。中途又可能锁自动过期了，又被其他客户端抢占了锁，导致删锁时把其他客户端占用的锁删了。

• 改进：使用 Lua 脚本进行获取锁、比较锁、删除锁的原子操作。

• 缺陷：非专业的分布式锁方案。

• 改进：Redission 分布式锁。

• https://www.bilibili.com/video/BV1np4y1C7Yf