基于 Redis 实现分布式锁

十二月 8, 2019 微服务架构

在并发编程中，我们通过锁，来避免由于竞争而造成的数据不一致问题。通常，我们以 synchronized 、Lock 来使用它。但是 Java 中的锁，只能保证在同一个 JVM 进程内中执行。如果在分布式集群环境下呢？分布式锁的实现有很多，比如基于数据库、memcached、Redis、系统文件、zookeeper 等。它们的核心的理念跟上面的过程大致相同。本篇文章，主要讲如何用 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
如果客户端获得锁，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 实例