与分布式锁相对应的是「单机锁」，我们在写多线程程序时，避免同时操作一个共享变量产生数据问题，通常会使用一把锁来「互斥」，以保证共享变量的正确性，其使用范围是在「同一个进程」中。

想要实现分布式锁，必须借助一个外部系统，所有进程都去这个系统上申请「加锁」。

而这个外部系统，必须要实现「互斥」的能力，即两个请求同时进来，只会给一个进程返回成功，另一个返回失败（或等待）。

这个外部系统，可以是 MySQL，也可以是 Redis 或 Zookeeper。但为了追求更好的性能，我们通常会选择使用 Redis 或 Zookeeper 来做。

想要实现分布式锁，必须要求 Redis 有「互斥」的能力，我们可以使用 SETNX 命令，这个命令表示SET if Not eXists，即如果 key 不存在，才会设置它的值，否则什么也不做。

两个客户端进程可以执行这个命令，达到互斥，就可以实现一个分布式锁。

客户端 1 申请加锁，加锁成功===========>127.0.0.1:6379> SETNX lock 1
(integer) 1 // 客户端1，加锁成功

操作完成后，还要及时释放锁，给后来者让出操作共享资源的机会。========>127.0.0.1:6379> DEL lock // 释放锁
(integer) 1

它存在一个很大的问题，当客户端 1 拿到锁后，如果发生下面的场景，就会造成「死锁」：

这时，这个客户端就会一直占用这个锁，而其它客户端就「永远」拿不到这把锁了

避免死锁

在 Redis 中实现时，就是给这个 key 设置一个「过期时间」

127.0.0.1:6379> SETNX lock 1 // 加锁
(integer) 1
127.0.0.1:6379> EXPIRE lock 10 // 10s后自动过期
(integer) 1

// 一条命令保证原子性执行
127.0.0.1:6379> SET lock 1 EX 10 NX

锁被别人释放

客户端在加锁时，设置一个只有自己知道的「唯一标识」进去。

// 锁的VALUE设置为UUID
127.0.0.1:6379> SET lock $uuid EX 20 NX
OK

在释放锁时，要先判断这把锁是否还归自己持有

// 锁是自己的，才释放
if redis.get("lock") == $uuid:
redis.del("lock")