在并发的样实场景下，很多时候，分布我们的式的锁业务开发中会有加锁的操作，以此来保证执行的公平互斥，保障业务逻辑。样实比如在 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

再来看解锁的逻辑。我前面加锁的一些内容对应着看，重点在于 「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

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

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