手写一个redis分布式锁，让你彻底搞懂

哈喽，大家好，我是指北君。

今天带大家深入剖析一下Redis分布式锁，彻底搞懂它。

场景

既然要搞懂Redis分布式锁，那肯定要有一个需要它的场景。

高并发售票问题就是一个经典案例。

搭建环境

1. 准备redis服务，设置redis的键值对：set ticket 10
2. 准备 postman、JMeter 等模拟高并发请求的工具
3. 核心代码

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

@Service public class TicketServiceImpl implements TicketService { @Autowired private StringRedisTemplate stringRedisTemplate; private Logger logger = LoggerFactory.getLogger(TicketServiceImpl.class); @Override public String sellTicket() { String ticketStr = stringRedisTemplate.opsForValue().get("ticket"); int ticket = 0; if (null != ticketStr) { ticket = Integer.parseInt(ticketStr); } if (ticket > 0) { int ticketNew = ticket - 1; stringRedisTemplate.opsForValue().set("ticket", String.valueOf(ticketNew)); logger.info("当前票的库存为：" + ticketNew); } else { logger.info("手速不够呀，票已经卖光了..."); } return "抢票成功..."; } }

分析解决问题

以上代码没有做任何的加锁操作，在高并发情况下，票的超卖情况很严重，根本无法正常使用

分析1

既然要加分布式锁，那么我们可以使用Redis中的setnx命令来模拟一个锁。

1 2 3 4 5 6 7 8

redis> EXISTS job # job 不存在 (integer) 0 redis> SETNX job "programmer" # job 设置成功 (integer) 1 redis> SETNX job "code-farmer" # 尝试覆盖 job ，失败 (integer) 0

当一个线程进入到当前方法中，使用 setnx 设置一个键，如果设置成功，就允许继续访问，设置失败，就不能访问该方法；

当方法运行完毕时，将这个键删除，下一次再有线程来访问时，就重新执行该操作。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

public String sellTicket() { String lock="lock"; // 如果成功设置这个值，证明目前该方法并没有被操作，可以进行卖票操作 Boolean tag = stringRedisTemplate.opsForValue().setIfAbsent(lock, ""); if (!tag) { // 如果设置失败，证明当前方法正在被执行，不允许再次执行 // 实际开发环境应该使用队列来完成访问操作，这里主要探究分布式锁的问题，所以仅仅模拟了场景 // 这里使用自旋的方式，防止访问信息丢失 sellTicket(); return "当前访问人数过多，请稍后访问..."; } String ticketStr = stringRedisTemplate.opsForValue().get("ticket"); int ticket = 0; if (null != ticketStr) { ticket = Integer.parseInt(ticketStr); } if (ticket > 0) { int ticketNew = ticket - 1; stringRedisTemplate.opsForValue().set("ticket", String.valueOf(ticketNew)); logger.info("当前票的库存为：" + ticketNew); } else { logger.info("手速不够呀，票已经卖光了..."); } stringRedisTemplate.delete(lock); return "抢票成功..."; }

分析2

上述的代码在程序正常运行下不会出现票超卖的问题，但是我们需要考虑：

1. 如果程序运行中系统出现了异常，导致无法删除lock，就会造成死锁的问题。也许有人马上就会想到，使用 try{} finally {} ，在finally中进行删除锁的操作。
   • 但是，如果是分布式架构，第一个服务器接收到请求，加了锁，此时第二个服务器也接收到请求，setnx 命令失败，需要执行return操作，根据finally的特性，执行return之前，需要先执行finally里的代码，于是，第二个服务器把锁给删除了，程序中锁失效了，肯定会出现票超卖等一系列问题。
2. 如果程序在运行中直接彻底死了（比如，程序员闲着没事儿，来了个 kill -9；或者断电），就算加了finally，finally也不能执行，还是会出现死锁问题

解决方法：

1. 给锁加一个标识符，只允许自己来操作锁，其他访问程序不能操作锁
2. 还要给锁加一个过期时间，这样就算程序死了，当时间过期后，还是能够继续执行

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

public String sellTicket() { String lock="lock"; // 锁的键 String lockId = UUID.randomUUID().toString(); // 锁的值：唯一标识 try{ // 如果成功设置这个值，证明目前该方法并没有被操作，可以进行卖票操作 // 添加一个过期时间，暂定为 30秒，这里的操作具有原子性，如果过期时间设置失败，键也会设置失败 Boolean tag = stringRedisTemplate.opsForValue().setIfAbsent(lock, lockId, 30, TimeUnit.SECONDS); if (!tag) { // 如果设置失败，证明当前方法正在被执行，不允许再次执行 // 实际开发环境应该使用队列来完成访问操作，这里主要探究分布式锁的问题，所以仅仅模拟了场景 // 不设置回调的话，访问信息会丢失 sellTicket(); return "当前访问人数过多，请稍后访问..."; } String ticketStr = stringRedisTemplate.opsForValue().get("ticket"); int ticket = 0; if (null != ticketStr) { ticket = Integer.parseInt(ticketStr); } if (ticket > 0) { int ticketNew = ticket - 1; stringRedisTemplate.opsForValue().set("ticket", String.valueOf(ticketNew)); logger.info("当前票的库存为：" + ticketNew); } else { logger.info("手速不够呀，票已经卖光了..."); } } finally { // 如果redis中的值，和当前的值一致，才允许删除锁。 if (lockId.equals(stringRedisTemplate.opsForValue().get(lock))) { stringRedisTemplate.delete(lock); } } return "抢票成功..."; }

分析3

写到这里已经可以解决大部分问题了，但是还需要考虑一个问题：

如果程序运行的极慢（硬件处理慢或者进行了GC），导致30秒已经到了，锁已经失效了，程序还没有运行完成，这时候，就会有另一个线程总想钻个空子，导致票的超卖问题。

• 这里我们可以使用 sleep 模拟一下

• 1 2 3 4 5 6 7 8 9 10 11

  .... if (ticket > 0) { try { // 为了测试方便，过期时间和线程暂停时间都改成了3秒 Thread.sleep(3000); } catch (InterruptedException e) { e.printStackTrace(); } int ticketNew = ticket - 1; stringRedisTemplate.opsForValue().set("ticket", String.valueOf(ticketNew)); ....

• 这样运行就会出现极其严重的超卖问题

那么该如何设置这个过期时间呢？继续加大？这显然是不合适的，因为无论多么大，总有可能出现问题。

解决方法

我们可以使用守护线程，来保证这个时间永不过期

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

public String sellTicket() { String lock="lock"; // 锁的键 String lockId = UUID.randomUUID().toString(); // 锁的值：唯一标识 MyThread myThread = null; // 锁的守护线程 try{ // 如果成功设置这个值，证明目前该方法并没有被操作，可以进行卖票操作 // 添加一个过期时间，暂定为 3 秒，这里的操作具有原子性，如果过期时间设置失败，键也会设置失败 Boolean tag = stringRedisTemplate.opsForValue().setIfAbsent(lock, lockId, 3, TimeUnit.SECONDS); if (!tag) { // 如果设置失败，证明当前方法正在被执行，不允许再次执行 // 实际开发环境应该使用队列来完成访问操作，这里主要探究分布式锁的问题，所以仅仅模拟了场景 // 不设置回调的话，访问信息会丢失 sellTicket(); return "当前访问人数过多，请稍后访问..."; } // 开启守护线程, 每隔三分之一的时间，给锁续命 myThread = new MyThread(lock); myThread.setDaemon(true); myThread.start(); String ticketStr = stringRedisTemplate.opsForValue().get("ticket"); int ticket = 0; if (null != ticketStr) { ticket = Integer.parseInt(ticketStr); } if (ticket > 0) { try { Thread.sleep(3000); } catch (InterruptedException e) { e.printStackTrace(); } int ticketNew = ticket - 1; stringRedisTemplate.opsForValue().set("ticket", String.valueOf(ticketNew)); logger.info("当前票的库存为：" + ticketNew); } else { logger.info("手速不够呀，票已经卖光了..."); } } finally { // 如果redis中的值，和当前的值一致，才允许删除锁。 if (lockId.equals(stringRedisTemplate.opsForValue().get(lock))) { // 程序运行结束，需要关闭守护线程 myThread.stop(); stringRedisTemplate.delete(lock); logger.info("释放锁成功..."); } } return "抢票成功..."; } /** 使用后台线程进行续命 * 守护线程 * 在主线程下 如果有一个守护线程 这个守护线程的生命周期 跟主线程是同生死的 */ class MyThread extends Thread{ String lock; MyThread (String lock) { this.lock = lock; } @Override public void run() { while (true) { try { // 三分之一的时间 Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } // 假设线程还活着，就要给锁续命 logger.info("线程续命ing..."); stringRedisTemplate.expire(lock, 3, TimeUnit.SECONDS); } } }

总结

到这里，我们已经基本实现了redis分布式锁，并且可以在高并发场景下正常运行。

需要注意的是，实现分布式锁的代码肯定不是最佳的，重要的是了解分布式锁的实现原理，以及发现问题并解决问题的思路。