分布式锁：

使用场景：

通常对于一些使用率高的服务，我们会进行多次部署，可能会部署在不同的服务器上，但是他们获取和操作的数据仍然是同一份。为了保证服务的强一致性，我们需要对线程进行加锁，但是因为我们部署在了不同的服务器上，而互斥锁只针对加锁的那台服务器，不会去限制别的服务器，所以是不能实现强一致性的要求的。（比如在8080的线程1获取完库存后，8081的线程1也进行了获取，此时8080的线程1对内存进行了扣除，按理来说已经没有库存了，但是8081的线程1获取的时候还是有的，还会继续扣除，这样就会出现问题）

这个时候我们就要使用分布式锁来解决问题了，分布式锁可以实现不同服务器上的监控，只要有一个线程获取了锁，其他的线程（包括其他服务器上的线程）都无法继续获取锁。

那么分布式锁怎么使用呢？通常我们使用redis的时候，会通过redis中的redission来实现分布式锁。

Redission：

redission实现分布式锁有三个重点：

watch dog：

我们知道，获取了锁之后如果不去释放锁，那么别的线程就都无法去使用相关的资源，那么如果加锁的线程因为某些原因终止了，没有去执行释放锁的命令怎么办呢？也许我们可以去设置锁的时间，到时间了就立马释放锁？这种方法理论可行，但是实际上每个线程需要花费的时间是无法确定的，如果时间少了加锁就没有意义，时间久了又占用资源。如果有一个旁观者，它可以告诉我们线程是否结束，如果结束了就释放锁，如果没结束就给锁加时就好了。watch dog就可以实现这个功能。

在某个线程加锁的同时，会生成一个新的线程来启动watch dog监控，如果加锁线程没有结束watch dog会每隔（releaseTime/3）的时间做一次续期（releaseTime默认30s），如果线程结束了，我们可以发送释放锁的指令来停止watch dog续期锁。

下面是redission的代码实现，这里有一个要注意的地方，如果我们在trylock的时候设置了锁自动释放时间，redission就会认为我们可以自己控制什么时候释放锁，就不会使用watch dog来帮助我们。

重试机制：

当有线程获取锁后，另外的线程会尝试循环获取锁，不过这个次数不是无限制的，存在一个阈值。

LUA脚本：

加锁、设置过期时间等操作都是基于lua脚本完成，可以保证代码的原子性。

除此之外，redission生成的分布式锁还有一些特点

可重录：

什么意思呢？就是在同一个线程中可以多次进行加锁（同一把锁），而每加一把锁，锁的value +1，每释放一把锁，锁的value -1。举个例子，在add1方法中，我们拿了一个“heimalock”锁，此时这个lock的记录如下

因为生成了锁，value为1，在add1方法中我们又调用了add2方法，add2方法同样也拿了一个“heimalock”锁，此时并不会创建新的锁，而是将value +1变成了2，此时这个lock的记录如下

释放锁其实就是value -1，不再过多赘述。

主从一致性：

redission不能实现，但是redission提供了redlock（红锁）来实现，只不过效率太低，如果要实现主从一致性，建议使用zookeeper