分布式锁在spring-cloud的实践.1

如果环境中部署了zk集群利用zk/node特性是容易实现分布式锁的功能，如何利用redis实现分布式锁呢？

一般来说，对数据进行加锁时，程序先通过acquire获取锁来对数据进行排他访问，然后对数据进行一些列的操作，最后需要释放锁。Redis 本身用 watch命令进行了加锁，这个锁是乐观锁。使用 watch命令对于频繁访问的键会引起性能的问题。

在redis事务http://redisbook.readthedocs.io/en/latest/feature/transaction.html中有4个命令： MULTI 、 DISCARD 、 EXEC 和 WATCH ；

>muti //开启事务
>set ...
>mset ...
...
>exec ; //提交事务

如果不是事务模式下的set命令，回立即返回OK；如果是事务状态，则返回QUEUED，表示进入了事务队列。

如果客户端正处于事务状态， 那么当 EXEC 命令执行时， 服务器根据客户端所保存的事务队列， 以先进先出（FIFO）的方式执行事务队列中的命令： 最先入队的命令最先执行， 而最后入队的命令最后执行。

事务中的命令和普通命令在执行上还是有一点区别的，其中最重要的两点是：

1. 非事务状态下的命令以单个命令为单位执行，前一个命令和后一个命令的客户端不一定是同一个；

   而事务状态则是以一个事务为单位，执行事务队列中的所有命令：除非当前事务执行完毕，否则服务器不会中断事务，也不会执行其他客户端的其他命令。

2. 在非事务状态下，执行命令所得的结果会立即被返回给客户端；

   而事务则是将所有命令的结果集合到回复队列，再作为 EXEC 命令的结果返回给客户端。

除了 EXEC 之外， 服务器在客户端处于事务状态时， 不加入到事务队列而直接执行的另外三个命令是 DISCARD 、 MULTI 和 WATCH。

DISCARD 命令用于取消一个事务， 它清空客户端的整个事务队列， 然后将客户端从事务状态调整回非事务状态， 最后返回字符串 OK 给客户端， 说明事务已被取消。

Redis 的事务是不可嵌套的， 当客户端已经处于事务状态， 而客户端又再向服务器发送 MULTI 时， 服务器只是简单地向客户端发送一个错误， 然后继续等待其他命令的入队。 MULTI 命令的发送不会造成整个事务失败， 也不会修改事务队列中已有的数据。

WATCH 只能在客户端进入事务状态之前执行， 在事务状态下发送 WATCH 命令会引发一个错误， 但它不会造成整个事务失败， 也不会修改事务队列中已有的数据（和前面处理 MULTI 的情况一样）。

WATCH 命令用于在事务开始之前监视任意数量的键： 当调用 EXEC 命令执行事务时， 如果任意一个被监视的键已经被其他客户端修改了， 那么整个事务不再执行， 直接

返回失败。

那么可以设想利用watch实现分布式锁的原理即watch一个key是否被watch，如果被watch则获锁失败。

Redis提供一些命令SETNX，GETSET，可以方便实现分布式锁机制。

命令介绍：

• SETNX命令（SET if Not eXists）

当且仅当 key 不存在，将 key 的值设为 value ，并返回1；若给定的 key 已经存在，则 SETNX 不做任何动作，并返回0。

• SETEX命令

设置超时时间

• GET命令

返回 key 所关联的字符串值，如果 key 不存在那么返回特殊值 nil 。

• DEL命令

删除给定的一个或多个 key ,不存在的 key 会被忽略。

相当于上面4个命令是原子性的。

由于redis的setnx命令天生就适合用来实现锁的功能，这个命令只有在键不存在的情况下为键设置值。获取锁之后，其他程序再设置值就会失败，即获取不到锁。获取锁失败。只需不断的尝试获取锁，直到成功获取锁，或者到设置的超时时间为止。

另外为了防治死锁，即某个程序获取锁之后，程序出错，没有释放，其他程序无法获取锁，从而导致整个分布式系统无法获取锁而导致一系列问题，甚至导致系统无法正常运行。这时需要给锁设置一个超时时间，即setex命令，锁超时后，从而其它程序就可以获取锁了。

项目地址：https://github.com/nick8sky/spring-clouds/tree/master/redis-setnx-lock