SpringBoot Redis分布式锁的正确实现方式

SpringBoot

对于大多数网友来说SpringBoot的相关介绍，如有不对的地方欢迎指正！

在说分布式锁之前，我们先说下为什么需要分布式锁。

在单机部署的时候，我们可以使用Java中提供的JUC锁机制避免多线程同时操作一个共享变量产生的安全问题。JUC 锁机制只能保证同一个 JVM 进程中的同一时刻只有一个线程操作共享资源。

一个应用部署多个节点，多个进程如果要修改同一个共享资源，为了避免操作乱序导致的并发安全问题，这个时候就需要引入分布式锁，分布式锁就是用来控制同一时刻，只有一个 JVM 进程中的一个线程可以访问被保护的资源。

分布式锁很重要，然而很多公司的系统可能还在跑着有缺陷的分布式锁方案，其中不乏一些大型公司。

所以，不念今天分享一个正确 Redis 分布式锁代码实战，让你一飞冲天，该代码可直接用于生产，不是简单的 demo。

温馨提示：如果你只想看代码实战部分，可直接翻到 SpringBoot 实战章节。

错误的分布式锁

说正确方案之前，先来一个错误的，知道错在哪，才能意识到如何写正确。

在银行工作的小白老师，使用 Redis SET 指令实现加锁， 指令满足了当 key 不存在则设置 value，同时设置超时时间，并且满足原子语意。

SET lockKey 1 NX PX expireTime

• lockKey表示锁的资源，value 设置成 1。
• NX：表示只有lockKey不存在的时候才能SET成功，从而保证只有一个客户端可以获得锁。
• PX expireTime设置锁的超时时间，单位是毫秒；也可以使用EX seconds以秒为单位设置超时时间。

至于解锁操作，小白老师果决的使用 DEL指令删除。一个分布式锁方案出来了，一气呵成，组员不明觉厉，纷纷竖起大拇指，伪代码如下。

//加锁成功
if（jedis.set(lockKey, 1, "NX", "EX", 10) == 1）{
  try {
      do work //执行业务
  } finally {
    //释放锁
     jedis.del(key);
  }
}

然而，这是一个错误的分布式锁。问题在于解锁的操作有可能出现释放别人的锁的情况。

有可能出现释放别人的锁的情况。

1. 客户端 A 获取锁成功，设置超时时间 10 秒。
2. 客户端 A 执行业务逻辑，但是因为某些原因（网络问题、FullGC、代码垃圾性能差）执行很慢，时间超过 10 秒，锁因为超时自动释放了。
3. 客户端 B 加锁成功。
4. 客户端 A 执行DEL释放锁，相当于把客户端 B 的锁释放了。
   123456下一页