对Redis分布式锁的一点错误理解

Redis 分布式锁在日常工作中经常用到，面试中也是高频问题，自己在看的时候，发现对于 Redlock 理解有些偏差，主要是 Redlock 是在单实例（单集群）还是多实例（多集群）下实现的。查资料的时候发现有这个问题的绝不止我一个，甚至很多人理解都是错的还写博客告诉别人。当然如果你已经知道了，看看我走过的弯路或许也会有些收获。

Redis 分布式锁的实现

在介绍 Redlock 之前，先看下一般情况下的实现方式。

加锁：

SET resource_name my_random_value NX PX 30000

解锁：

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

这是一段 lua 脚本，意思是：当 key 存在并且值恰好等于给定的值时，才删除 key

这里有几个需要注意的点

• 用 SET 命令就够了，SETNX 和 EXPIRE 组合使用无法保证原子性。
• my_random_value，唯一值，配合解锁的 lua 脚本看，用于删除时确保只有加锁成功的客户端才能释放锁。
• NX：只在 key 不存在时，才设置。不能变
• PX：过期时间，单位为毫秒。如果改为 EX，单位变为秒。这两个选项无法同时存在。

如果是面试，当你说出是如何实现的，面试官可能就会问这种实现有什么问题。

Redis 分布式锁的问题

首先如果是单节点，节点一挂，锁就没了，等节点再重启，别的客户端就可以获取到锁，也就是两个客户端都有锁了，这就有问题了。

可以添加一个 slave 节点，当 master 节点挂了可以切换到 slave，但是还会有问题，因为 Redis 默认是异步进行主从同步的，比如以下场景：

1. 客户端 A 获取 master 中的锁。
2. 在将 key 的写入传输到 slave 之前，master 崩溃。
3. slave 晋升为 master
4. 客户端 B 获取了客户端 A 已经获取到的锁。

如何解决这种问题呢，Redis 官网有一种算法实现，Redlock。

Redlock

加锁的过程

1. 客户端获取当前时间，单位毫秒
2. 尝试依次获取 N 个实例中的锁，在所有实例中使用相同的 key 和随机值。在每个实例中设置 key 的时候，客户端会设置一个超时时间，这个超时时间应该小于锁的有效时间，以防节点已经挂掉。例如锁有效时间为 10 秒，则超时时间应该在 5-50 毫秒之间。
3. 客户端通过从当前时间中减去在步骤 1 中获得的时间戳，来计算获取锁所花费的时间。当且仅当客户端能够在大多数实例中获得锁（超过一半）且获取锁所花费的总时间少于锁的有效时间，才认为已经获取到锁。
4. 如果获取了锁，则将其有效时间视为初始有效时间减去获取锁所使用的时间（步骤 3 计算的结果）。实例中每个 key 的过期时间是初始有效时间，而这一步计算的有效时间只是用于给客户端使用，并不会设置到 redis 中。
5. 如果客户端由于某种原因（无法锁定 N / 2 + 1 个实例或有效时间为负）而未能获得该锁，则它将尝试解锁所有实例（即便某些 Redis 实例根本就没有加锁成功，防止某些节点获取到锁但是客户端没有得到响应而导致接下来的一段时间不能被重新获取锁）。

问题就在于，对于 N 个实例的理解，我最开始以为可以是集群中的多个 master 节点，但是问题就来了，如何在同一个集群中多个 master 设置相同的 key。

走了很多弯路，最后发现是多个实例（多集群），也就是这些实例之间并没有任何关系，这样也可以理解为什么可以在每个实例设置相同的 key 以及为什么控制多数加锁成功的判断需要放在客户端了。但是在实际场景中就不大可能会使用，因为实现 Redlock 最少需要三个节点，生产环境基本都是集群，也就是为了加锁就需要至少连接 3 个集群。什么情况下一个服务会连多个 Redis 集群呢，多级缓存？每个 Redis 是不同业务的缓存？我还没了解过。

如果这是面试官期待的基于 Redis 分布式加锁解决方案，我觉得这个面试官可能也理解的有点问题。

奇怪的知识

走弯路的时候也了解了不少新的知识

redis-cli -c 参数

帮助中对于 -c 是这么描述的

Enable cluster mode (follow -ASK and -MOVED redirections).

虽然说是启用集群模式，但并不是服务端分单机模式还是集群模式，只是加了 -c 会自动进行重定向。

开始没加 -c 去请求一个不在本节点存储的 key ，会返回重定向信息，而如果加上，会自动进行重定向。

key 所属的哈希槽的计算

集群情况下，key 属于哪个哈希槽是在客户端计算的还是服务端？

服务端肯定是有的，如果只在客户端进行，那就相当于加了一层查询路由，一致性需要由这一层保证，而在服务端没有任何保证，这肯定是不对的。而且像上面给出的重定向信息，说明服务端肯定是计算过的。

客户端一般也会有，只是当作缓存，每次直接选择存放 key 的节点，而不需要频繁的进行重定向。

一般如果是集群的话，最开始客户端就会建立整个集群的拓扑，获取每个节点保存那些槽位，但是后续如果节点和槽位的映射关系变化了，具体的刷新策略就看每个客户端的实现了。