分布式锁实现原理与最佳实践（4）

04 常见分布式锁的原理

4.1 Redisson

Redis 2.6之后才可以执行lua脚本，比起管道而言，这是原子性的，模拟一个商品减库存的原子操作：

//lua脚本命令执行方式：redis-cli --eval /tmp/test.lua , 10
jedis.set("product_stock_10016", "15");
//初始化商品10016的库存
String script = " local count = redis.call('get', KEYS[1]) " +
        " local a = tonumber(count) " +
        " local b = tonumber(ARGV[1]) " +
        " if a >= b then " +
        "   redis.call('set', KEYS[1], a-b) " +
        "   return 1 " +
        " end " +
        " return 0 ";
Object obj = jedis.eval(script, Arrays.asList("product_stock_10016"),
                        Arrays.asList("10"));
System.out.println(obj);

✪ 4.1.1 尝试加锁的逻辑

上面的org.redisson.RedissonLock#lock()通过调用自己方法内部的lock方法的org.redisson.RedissonLock#tryAcquire方法。之后调用 org.redisson.RedissonLock#tryAcquireAsync：

首先调用内部的org.redisson.RedissonLock#tryLockInnerAsync：设置对应的分布式锁

到这里获取锁的逻辑就结束了，如果这里没有获取到，在Future的回调里面就会直接return，会在外层有一个while true的循环，订阅释放锁的消息准备被唤醒。如果说加锁成功，就开始执行锁续命逻辑。

✪ 4.1.2 锁续命逻辑

lua脚本最后是以毫秒为单位返回key的剩余过期时间。成功加锁之后org.redisson.RedissonLock#scheduleExpirationRenewal中将会调用org.redisson.RedissonLock#renewExpiration，这个方法内部就有锁续命的逻辑，是一个定时任务，等10s执行。

执行的时候尝试执行的续命逻辑使用的是Lua脚本，当前的锁有值，就续命，没有就直接返回0：

返回0之后外层会判断，延时成功就会再次调用自己，否则延时调用结束，不再为当前的锁续命。所以这里的续命不是一个真正的定时，而是循环调用自己的延时任务。

✪ 4.1.3 循环间隔抢锁机制

如果一开始就加锁成功就直接返回。

如果一开始加锁失败，没抢到锁的线程就会在while循环中尝试加锁，加锁成功就结束循环，否则等待当前锁的超时时间之后再次尝试加锁。所以实现逻辑默认是非公平锁：

里面有一个subscribe的逻辑，会监听对应加锁的key，当锁释放之后publish对应的消息，此时如果没有到达对应的锁的超时时间，也会尝试获取锁，避免时间浪费。

✪ 4.1.4 释放锁和唤醒其他线程的逻辑

前面没有抢到锁的线程会监听对应的queue，后面抢到锁的线程释放锁的时候会发送一个消息。