说说Redis分布式锁是如何实现的。含Redis面试专题及答案

前言

近来，分布式的问题被广泛提及，比如分布式事务、分布式框架、ZooKeeper、SpringCloud等等。本文先回顾锁的概念，再介绍分布式锁，以及如何用Redis来实现分布式锁。

一、锁的基本了解

首先，回顾一下我们工作学习中的锁的概念。

为什么要先讲锁再讲分布式锁呢？

我们都清楚，锁的作用是要解决多线程对共享资源的访问而产生的线程安全问题，而在平时生活中用到锁的情况其实并不多，可能有些朋友对锁的概念和一些基本的使用不是很清楚，所以我们先看锁，再深入介绍分布式锁。

通过一个卖票的小案例来看，比如大家去抢dota2 ti9门票，如果不加锁的话会出现什么问题？此时代码如下：

**代码分析：**这里有8张ti9门票，设置了10个线程（也就是模拟10个人）去并发抢票，如果抢成功了显示成功，抢失败的话显示失败。按理说应该有8个人抢成功了，2个人抢失败，下面来看运行结果：

我们发现运行结果和预期的情况不一致，居然10个人都买到了票，也就是说出现了线程安全的问题，那么是什么原因导致的呢？

原因就是多个线程之间产生了时间差。

如图所示，只剩一张票了，但是两个线程都读到的票余量是1，也就是说线程B还没有等到线程A改库存就已经抢票成功了。

怎么解决呢？想必大家都知道，加个synchronized关键字就可以了，在一个线程进行reduce方法的时候，其他线程则阻塞在等待队列中，这样就不会发生多个线程对共享变量的竞争问题。

举个例子

比如我们去健身房健身，如果好多人同时用一台机器，同时在一台跑步机上跑步，就会发生很大的问题，大家会打得不可开交。如果我们加一把锁在健身房门口，只有拿到锁的钥匙的人才可以进去锻炼，其他人在门外等候，这样就可以避免大家对健身器材的竞争。代码如下：

运行结果：

果不其然，结果有两个人没有成功抢到票，看来我们的目地达成了。

二、锁的性能优化

2.1 缩短锁的持有时间

事实上，按照我们对日常生活的理解，不可能整个健身房只有一个人在运动。所以我们只需要对某一台机器加锁就可以了，比如一个人在跑步，另一个人可以去做其他的运动。

对于票务系统来说，我们只需要对库存的修改操作的代码加锁就可以了，别的代码还是可以并行进行，这样会大大减少锁的持有时间，代码修改如下：

这样做的目的是充分利用cpu的资源，提高代码的执行效率。

这里我们对两种方式的时间做个打印：

果然，只对部分代码加锁会大大提供代码的执行效率。

所以，在解决了线程安全的问题后，我们还要考虑到加锁之后的代码执行效率问题。

2.2 减少锁的粒度

举个例子，有两场电影，分别是最近刚上映的魔童哪吒和蜘蛛侠，我们模拟一个支付购买的过程，让方法等待，加了一个CountDownLatch的await方法，运行结果如下：

执行结果：

魔童哪吒的剩余票数为：20

我们发现买哪吒票的时候阻塞会影响蜘蛛侠票的购买，而实际上，这两场电影之间是相互独立的，所以我们需要减少锁的粒度，将movie整个对象的锁变为两个全局变量的锁，修改代码如下：

执行结果：

魔童哪吒的剩余票数为：20

蜘蛛侠的剩余票数为：100

现在两场电影的购票不会互相影响了，这就是第二个优化锁的方式：减少锁的粒度。顺便提一句，Java并发包里的ConcurrentHashMap就是把一把大锁变成了16把小锁，通过分段锁的方式达到高效的并发安全。

2.3 锁分离

锁分离就是常说的读写分离，我们把锁分成读锁和写锁，读的锁不需要阻塞，而写的锁要考虑并发问题。

三、锁的种类

• 公平锁： ReentrantLock
• 非公平锁： Synchronized、ReentrantLock、cas
• 悲观锁： Synchronized
• 乐观锁：cas
• 独享锁：Synchronized、ReentrantLock
• 共享锁：Semaphore

这里就不一一讲述每一种锁的概念了，大家可以自己学习，锁还可以按照偏向锁、轻量级锁、重量级锁来分类。

四、Redis分布式锁

了解了锁的基本概念和锁的优化后，重点介绍分布式锁的概念。

上图所示是我们搭建的分布式环境，有三个购票项目，对应一个库存，每一个系统会有多个线程，和上文一样，对库存的修改操作加上锁，能不能保证这6个线程的线程安全呢？

当然是不能的，因为每一个购票系统都有各自的JVM进程，互相独立，所以加synchronized只能保证一个系统的线程安全，并不能保证分布式的线程安全。

所以需要对于三个系统都是公共的一个中间件来解决这个问题。

这里我们选择Redis来作为分布式锁，多个系统在Redis中set同一个key，只有key