17. Redis 分布式锁

1. 系统是一个分布式系统（关键是分布式，单机的可以使用ReentrantLock或者synchronized代码块来实现）
2. 共享资源（各个系统访问同一个资源，资源的载体可能是传统关系型数据库或者NoSQL）
3. 同步访问（即有很多个进程同事访问同一个共享资源。没有同步访问，谁管你资源竞争不竞争）

long N=0L;
//N从redis获取值
if(N<5){
N++；
//N写回redis
}

• 语法：SETNX key value
• 将 key 的值设为 value ，当且仅当 key 不存在。
• 若给定的 key 已经存在，则 SETNX 不做任何动作。
• SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写
• 返回值：
  • 设置成功，返回 1 。
  • 设置失败，返回 0 。
• 例子：

  redis> EXISTS job                # job 不存在
  (integer) 0
  redis> SETNX job "programmer"    # job 设置成功
  (integer) 1
  redis> SETNX job "code-farmer"   # 尝试覆盖 job ，失败
  (integer) 0
  redis> GET job                   # 没有被覆盖
  "programmer"
  

• 所以我们使用执行下面的命令

  SETNX lock.foo <current Unix time + lock timeout + 1>
  

• 如返回1，则该客户端获得锁，把lock.foo的键值设置为时间值表示该键已被锁定，该客户端最后可以通过DEL lock.foo来释放该锁。
• 如返回0，表明该锁已被其他客户端取得，这时我们可以先返回或进行重试等对方完成或等待锁超时。

• 语法：GETSET key value
• 将给定 key 的值设为 value，并返回 key 的旧值(old value)。
• 当 key 存在但不是字符串类型时，返回一个错误。
• 返回值：
  • 返回给定 key 的旧值。

    当 key 没有旧值时，也即是， key 不存在时，返回 nil 。
    

• 语法：GET key
• 返回值：
  • 当 key 不存在时，返回 nil ，否则，返回 key 的值。
  • 如果 key 不是字符串类型，那么返回一个错误。

我们可以通过锁的键对应的时间戳来判断这种情况是否发生了，如果当前的时间已经大于lock.foo的值，说明该锁已失效，可以被重新使用。

C0操作超时了，但它还持有着锁，C1和C2读取lock.foo检查时间戳，先后发现超时了。 C1 发送DEL lock.foo C1 发送SETNX lock.foo 并且成功了。 C2 发送DEL lock.foo C2 发送SETNX lock.foo 并且成功了。 这样一来，C1，C2都拿到了锁！问题大了！

C3发送SETNX lock.foo 想要获得锁，由于C0还持有锁，所以Redis返回给C3一个0 C3发送GET lock.foo 以检查锁是否超时了，如果没超时，则等待或重试。 反之，如果已超时，C3通过下面的操作来尝试获得锁： GETSET lock.foo <current Unix time + lock timeout + 1> 通过GETSET，C3拿到的时间戳如果仍然是超时的，那就说明，C3如愿以偿拿到锁了。

lock(key, expireSec){
isSuccess =
 setnx key
if
 (isSuccess)
expire key expireSec
}

• C0超时了，还持有锁,C1/C2同时请求进入了方法里面
• C1/C2获取到了C0的超时时间
• C1使用getSet方法
• C2也执行了getSet方法