在并发编程中，我们通过锁，来避免由于竞争而造成的数据不一致问题。通常，我们以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的几个命令

www.redis.cn/commands/se… 可以先看看这个文档：

第一个命令：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：