怎样实现一个分布式的公平锁?

开发 前端
对于需要公平的场景,和我们真实生活一样,这里的 FairSync 会通过一个 CLH 队列将请求线程排队。

在并发的场景下,很多时候,我们的业务开发中会有加锁的操作,以此来保证执行的互斥,保障业务逻辑。比如在 Java 里就有多种基于 AQS 的组件,方便使用。创建锁的时候,还可以特别的指定一下,当前这个锁,是否需要公平。

 /**
* Creates an instance of {@code ReentrantLock} with the
* given fairness policy.
*
* @param fair {@code true} if this lock should use a fair ordering policy
*/
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}

对于需要公平的场景,和我们真实生活一样,这里的 FairSync 会通过一个 CLH 队列将请求线程排队。

在单实例应用中,本机的 CLH 排队就足够了,我们现在切换到分布式的场景。

在分布式场景下,为了实现锁的功能,就出现了各种分布式锁。相比单实例场景下的锁只能锁定自己的实例,分布式的锁由于统一的外部中间件的介入,将锁的信息提取到独立的外部,所以可以将多个应用实例做到互斥。

那分布式的场景下,怎么样能保证公平呢?

和我们从单实例到分布式加锁的思路一样,要公平,就排队,在统一的第三方处进行排队。

来第三方这里排队,也有一些需要注意的点。比如你在判断当前队列里有没有等待,如果没有就取锁成功,执行,有等待就入队,而判断的这个逻辑,仍然可能是并发操作,也需要做到加锁处理。就好像你看了一眼某个饭店没什么人,开心的去买了杯奶茶,回来一看满了。

对于分布式锁,基于 Redis 的 Redission 用得不少。如果换成Redis 分布式公平锁,那基本就只有 Redission 了。

下面我通过两段代码,以及部分文字,描述下 Redission 的公平锁的实现。

简要概括下:

Redission 的公平锁,是通过「 Redis + Lua 脚本」来实现的。在拿到一个 Redission 的 Redis 连接之后,通过 「eval()」可以执行一段 Lua script,同时传入一些 key 和 args。因为不管有多少 Lua 的逻辑,都是在同一个连接内,所以不会存在买完奶茶发现人满了的情况。这里应用到了 Redis 的 pub/sub 功能,等待的线程,会在轮到自己时收到 Redis 的提醒,前提是需要订阅了相应的通知。

来看加锁的 Lua 逻辑,代码写的比较清楚,我也加了些对应的Redis操作以及参数的注释。通过 list 来存储排队信息,同时每个等待线程都有一个超时时间,超时退出队列。 所以eval 执行这个的时候,返回的是一个 ttl Long 类型。表示过期时间。

[[

用于 lock 操作。

KEYS[1] = lockName
KEYS[2] = waitQueueName
KEYS[3] = timeoutName

ARGV[1] = waitTime
ARGV[2] = lockName
ARGV[3] = leaseTime
ARGV[4] = currentTime
--]]

while true do
local firstThreadId2 = redis.call("lindex", KEYS[2], 0)
if firstThreadId2 == false then
break
end
local timeout = tonumber(redis.call("zscore", KEYS[3], firstThreadId2))
if timeout <= tonumber(ARGV[4]) then
redis.call("zrem", KEYS[3], firstThreadId2)
redis.call("lpop", KEYS[2])
else
break
end
end
if
(redis.call("exists", KEYS[1]) == 0) and
((redis.call("exists", KEYS[2]) == 0) or (redis.call("lindex", KEYS[2], 0) == ARGV[2]))
then
redis.call("lpop", KEYS[2])
redis.call("zrem", KEYS[3], ARGV[2]) -- 移除有序集合中的一个或多个成员
redis.call("hset", KEYS[1], ARGV[2], 1) -- 将哈希表 key 中的字段 field 的值设为 value 。
redis.call("pexpire", KEYS[1], ARGV[1])
return nil
end
if (redis.call("hexists", KEYS[1], ARGV[2]) == 1) then -- HEXISTS key field 查看哈希表 key 中,指定的字段是否存在。
redis.call("hincrby", KEYS[1], ARGV[2], 1) -- HINCRBY key field increment 为哈希表 key 中的指定字段的整数值加上增量 increment 。
redis.call("pexpire", KEYS[1], ARGV[1]) -- Redis PEXPIRE 命令和 EXPIRE 命令的作用类似,但是它以毫秒为单位设置 key 的生存时间,而不像 EXPIRE 命令那样,以秒为单位。
return nil
end
local firstThreadId = redis.call("lindex", KEYS[2], 0)
local ttl
if firstThreadId ~= false and firstThreadId ~= ARGV[2] then
ttl = tonumber(redis.call("zscore", KEYS[3], firstThreadId)) - tonumber(ARGV[4])
else
ttl = redis.call("pttl", KEYS[1]) -- Redis Pttl 命令以毫秒为单位返回 key 的剩余过期时间。
end
local timeout = ttl + tonumber(ARGV[3]) + tonumber(ARGV[4])
if redis.call("zadd", KEYS[3], timeout, ARGV[2]) == 1 then
redis.call("rpush", KEYS[2], ARGV[2])
end
return ttl

再来看解锁的逻辑。我前面加锁的一些内容对应着看,重点在于 「publish」这里,在轮到某个线程时,nextThreadId 这个 channel 会收到通知。

这里的 threadId 是我们在加锁和解锁的时候都需要传入的。如果你留意过 Java 的线程 Id 就会发现,不同实例之间有很大概率会重复的。为了避免,各个 Client 在传入 ThradId 的时候,除了真实的 id 外,还需要加入各个 client 对应的信息加以区分。


--[[
用于 unlock 操作。

KEYS[1] = lockName
KEYS[2] = waitQueueName
KEYS[3] = timeoutName
KEYS[4] = channelName

ARGV[1] = message
ARGV[2] = leaseTime
ARGV[3] = lockName
ARGV[3] = currentTime
--]]

while true do
local firstThreadId2 = redis.call("lindex", KEYS[2], 0)
if firstThreadId2 == false then
break
end
local timeout = tonumber(redis.call("zscore", KEYS[3], firstThreadId2))
if timeout <= tonumber(ARGV[4]) then
redis.call("zrem", KEYS[3], firstThreadId2)
redis.call("lpop", KEYS[2])
else
break
end
end

if (redis.call("exists", KEYS[1]) == 0) then
local nextThreadId = redis.call("lindex", KEYS[2], 0)
if nextThreadId ~= false then
redis.call("publish", KEYS[4] .. ":" .. nextThreadId, ARGV[1])
end
return 1
end
if (redis.call("hexists", KEYS[1], ARGV[3]) == 0) then
return nil
end
local counter = redis.call("hincrby", KEYS[1], ARGV[3], -1)
if (counter > 0) then
redis.call("pexpire", KEYS[1], ARGV[2])
return 0
end

redis.call("del", KEYS[1])
local nextThreadId = redis.call("lindex", KEYS[2], 0)
if nextThreadId ~= false then
redis.call("publish", KEYS[4] .. ":" .. nextThreadId, ARGV[1])
end
return 1

看过了解锁逻辑后,外面eval 执行加锁的时候,需要对应有 sub ,才会收到这里解锁的 pub 信息,否则就卡住了。

这里需要注意下,sub 这个功能是个阻塞操作,需要单独的线程里执行,通过一个 Future 来实现一定等待时间的 sub 功能,超时再 unsub。这块逻辑 Redission 封装的比较多,感兴趣的可以到源码里点点。

责任编辑:武晓燕 来源: Tomcat那些事儿
相关推荐

2020-07-30 09:35:09

Redis分布式锁数据库

2021-11-01 12:25:56

Redis分布式

2021-07-02 08:51:09

Redisson分布式锁公平锁

2024-05-08 10:20:00

Redis分布式

2021-06-30 14:56:12

Redisson分布式公平锁

2021-07-01 09:42:08

Redisson分布式

2024-02-19 00:00:00

Redis分布式

2023-09-21 22:22:51

开发分布式锁

2023-03-06 08:14:48

MySQLRedis场景

2022-09-29 08:28:57

SpringRedis分布式

2022-09-22 13:28:34

Redis分布式锁

2023-09-04 08:45:07

分布式配置中心Zookeeper

2019-02-26 09:51:52

分布式锁RedisZookeeper

2017-01-16 14:13:37

分布式数据库

2018-04-03 16:24:34

分布式方式

2017-04-13 10:51:09

Consul分布式

2022-04-08 08:27:08

分布式锁系统

2021-02-28 07:49:28

Zookeeper分布式

2019-06-19 15:40:06

分布式锁RedisJava

2023-08-21 19:10:34

Redis分布式
点赞
收藏

51CTO技术栈公众号