Redis 分布式锁的关键命令

前言

分布式或集群环境下，由于 JVM 锁只能保证单台服务器的线程安全，所以需要使用分布式锁。

Redis分布式锁的关键命令

实现原子性的加锁操作：

SET key random_value NX PX 30000

• random_value：是由客户端生成的一个随机字符串，它要保证在足够长的一段时间内在所有客户端的所有获取锁的请求中都是唯一的。value 的值设置为随机数主要是为了更安全的释放锁，释放锁的时候需要检查 key 是否存在，且 key 对应的值是否和我指定的值一样，是一样的才能释放锁。所以可以看到这里有获取、判断、删除三个操作，为了保障原子性，我们需要用 lua 脚本。

• NX：表示只有当要设置的 key 值不存在的时候才能 set 成功。这保证了只有第一个请求的客户端才能获得锁，而其它客户端在锁被释放之前都无法获得锁。

• PX 30000：表示这个锁有一个 30 秒的自动过期时间。当然，这里 30 秒只是一个例子，客户端可以选择合适的过期时间。

不过在集群环境下，上述方式是存在问题的。比如在Sentinel 集群中，主节点挂掉时，从节点会取而代之，客户端上却并没有明显感知。原先第一个客户端在主节点中申请成功了一把锁，但是这把锁还没有来得及同步到从节点，主节点突然挂掉了。然后从节点变成了主节点，这个新的节点内部没有这个锁，所以当另一个客户端过来请求加锁时，立即就批准了。这样就会导致系统中同样一把锁被两个客户端同时持有，不安全性由此产生。

为了解决这个问题，Antirez 发明了 Redlock 算法。为了使用 Redlock，需要提供多个Redis 实例，这些实例之前相互独立没有主从关系。同很多分布式算法一样，Redlock 也使用「大多数机制」。加锁时，它会向过半节点发送 set(key, value, nx=True, ex=xxx)指令，只要过半节点 set 成功，那就认为加锁成功。释放锁时，需要向所有节点发送 del 指令。不过 Redlock 算法还需要考虑出错重试、时钟漂移等很多细节问题，同时因为Redlock 需要向多个节点进行读写，意味着相比单实例Redis 性能会下降一些。关于RedLock 算法不完美的地方，读者可以参考以下两篇博文：

• How to do distributed locking
• 【求锤得锤的故事】Redis锁从面试连环炮聊到神仙打架。