基于 Redis 实现分布式锁

1、秒杀示例

首先，下面的例子是一个特价商品得秒杀案例，直接看代码

服务层

单个电脑上直接拿鼠标点链接肯定不会有问题，因为是串行的操作，接下用使用 Apache ab 工具模拟并发的情况：

http://httpd.apache.org/docs/2.0/programs/ab.html 这个是它的官网，使用说明里面也有，下面直接使用它进行模拟测压：

经过测试之后发现：卖超了，意料之中的事情

为什么会出现这种情况呢？ 没有做同步呗，很正常，首先要解决的是数据同步问题

使用 synchronized 对方法加锁：

加了 synchronized 之后肯定是数据同步了：

但是速度却太慢了，无法实现细粒度控制，而且系统根本无法实现水平拓展，问题很多，下面用分布式锁来解决这些问题。

2、Redis 的几个命令

http://www.redis.cn/commands/setnx.html 可以先看看这个文档：

第一个命令：SETNX

Design pattern: Locking with !SETNX
设计模式：使用!SETNX 加锁
Please note that:
请注意：
不鼓励以下模式来实现 the Redlock algorithm ，该算法实现起来有一些复杂，但是提供了更好的保证并且具有容错性。
无论如何，我们保留旧的模式，因为肯定存在一些已实现的方法链接到该页面作为引用。而且，这是一个有趣的例子说明 Redis 命令能够被用来作为编程原语的。
无论如何，即使假设一个单例的加锁原语，但是从 2.6.12 开始，可以创建一个更加简单的加锁原语，相当于使用 SET 命令来获取锁，并且用一个简单的 Lua 脚本来释放锁。该模式被记录在 SET 命令的页面中。
也就是说，SETNX 能够被使用并且以前也在被使用去作为一个加锁原语。例如，获取键为 foo 的锁，客户端可以尝试一下操作：
SETNX lock.foo <current Unix time + lock timeout + 1>
如果客户端获得锁，SETNX 返回 1，那么将 lock.foo 键的 Unix 时间设置为不在被认为有效的时间。客户端随后会使用 DEL lock.foo 去释放该锁。
如果 SETNX 返回 0，那么该键已经被其他的客户端锁定。如果这是一个非阻塞的锁，才能立刻返回给调用者，或者尝试重新获取该锁，直到成功或者过期超时。

第二个命令：GETSET

自动将 key 对应到 value 并且返回原来 key 对应的 value。如果 key 存在但是对应的 value 不是字符串，就返回错误。

设计模式

GETSET 可以和 INCR 一起使用实现支持重置的计数功能。举个例子：每当有事件发生的时候，一段程序都会调用 INCR 给 key mycounter 加 1，但是有时我们需要获取计数器的值，并且自动将其重置为 0。这可以通过 GETSET mycounter “0”来实现：

其实就是先 GET、再 SET，所以返回 SET 之前的值

3、使用 Redis 实现分布式锁

首先搞清楚锁的是什么，即搞清楚什么是进行同步和互斥的数据，对于上面的秒杀系统示例程序来说，当然是商品，而且是同样的商品需要同步与互斥，假设现在是华为 Mate30 Pro 的秒杀活动，大家肯定买的都是这一款产品，所以其实需要关心的就是成交订单量和库存的关系，如果不进行同步与互斥，那么肯定会出现买超的情况，限量秒杀 1000 台，可能实际成交订单变成了 1200 或更多，所以需要进行数据的同步与互斥

我直接使用 Docker 跑了一个 Redis 实例

测试通过可以使用！

pom 文件引入 redis-starter

写入最基础的连接配置

RedisLock 实现:

在秒杀系统中使用：

在设计的时候把商品的 Id 设置为 Key，当前时间 + 超时时间为 Value

通过代码注释可以看清楚实现流程：

如果锁未超时也是返回 False，这说明别的线程已经持有锁！

4、Redis 分布式锁的好处

保证了数据的同步与互斥，通过模拟 10 个线程模拟 500 次请求的结果，对了我还统计了一下未能成功获得锁的请求次数，本次实验是 469 次请求未能成功获得锁，所以订单成交了 31 个，仓库剩余 99969 份！

另外分布式锁可以很好的支持分布式部署，本例中因为为了方便直接在一个服务中写死了，所以就不演示集群似的测试了。

效率上也是很大的进步：

使用 Redis 分布式锁：

使用 synchronized：