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