分布式锁续约问题

Redis的分布式锁实现原理网上已经有很多文章了，这里主要记录一下续约问题。

一般情况下，分布式锁是直接申请固定时间的锁（例如60S），然后在固定时间内执行完逻辑并解锁，这种适合业务操作量小，并发高的场景，但是不太适合用来大量业务操作的场景，随着数据增长，一个数据处理的定时任务所需要的时间是很难估计的。

Redis官方推荐用Redisson来做分布式锁，并且这个驱动是实现了锁续约的，当锁时间超过2/3，会自动刷新Redis那边（续约）。然而这个驱动并没有集成到Spring Cloud中，个人更建议使用官方推荐的驱动（JRedis, Lettuce）。

Spring官方提供了另外一个分布式锁实现，看代码，是有一个localLock 和远端的 redis锁，性能更优异，然而没提供远端续约方法，如果本地运行时间超过远端设置的超时时间，会报异常提示数据可能存在风险：

Lock was released in the store due to expiration.The integrity of data protected by this lock may have been compromised.

看源代码看到Redis的操作指令

private static final String OBTAIN_LOCK_SCRIPT =
            "local lockClientId = redis.call('GET', KEYS[1])\n" +
                    "if lockClientId == ARGV[1] then\n" +
                    "  redis.call('PEXPIRE', KEYS[1], ARGV[2])\n" +
                    "  return true\n" +
                    "elseif not lockClientId then\n" +
                    "  redis.call('SET', KEYS[1], ARGV[1], 'PX', ARGV[2])\n" +
                    "  return true\n" +
                    "end\n" +
                    "return false";

如果lockClientId == 当前传递过去的参数（当前的client），则为线程重入锁，刷新超时时间，否则设置为新锁

然后解锁位置

@Override
public void unlock() {
    ......
    if (this.localLock.getHoldCount() > 1) {
        this.localLock.unlock();
        return;
    }
    //解远端
    ......
}

先看看本地锁的计数，如果holdCount > 1（有其他地方获取了），先降1，等降到=1时候再去解远端

那么就有可以这样凑巧着用

if (lock.tryLock()) {
    try {
        while(...){
            try{
                //线程重入，本地holdCount++，刷新远端超时时间
                lock.lock()
                //这里是业务逻辑分片，需要保证在规定时间内完成（不超过锁时间）
                ......
            }finally{
                //线程重入，本地holdCount--,远端不变
                lock.unlock();
            }
        }
    } finally{
        //这里会解开远端
        lock.unlock();
    }
}

好像还是有点苟且，但适合这边的场景：一次处理一批数据（数据量会增长，但是单批次处理时间不会有太大增长）；更好的方式还是像Redisson那样，根据运行情况，另外找个timer去刷锁的有过期时间比较好（不知道是不是timer，没看源代码，只是猜...）

最后编辑于：2019.11.21 15:06:36