Redis——Redis分布式锁原理探究及java实现

·  阅读 282

简介

redis除了用作缓存,还经常被用来作为分布式锁。
redis分布式锁原理基础:redis是单线程的,所有客户端的请求都会以串行的方式执行;redis的操作是原子性的,能够保证数据的一致性。

锁超时问题

假如服务A和B均请求某个锁,此时服务A获得获得锁。A还没来得及释放锁就出现突发情况宕机了,如果没有一种超时机制,那么锁将无法释放,服务B则永远无法获得该锁。
此时可以在加锁的时候加上一个超时时间,当持有锁超过该时间限制,自动释放该锁。像上面的情况,服务A宕机了锁没有立即得到释放,等到超时自动释放该锁。
这里有出现一个问题,要如何设置这个超时时间呢?
如果服务A持有该锁然后进行一个比较长时间的作业,作业过程锁超时了自动释放了该锁,然后服务B拿到了该锁。
等到服务A完成作业后再去释放锁,但是此时锁是服务B持有而不是服务A持有。如果刚好有另一个服务C在等待该锁,那么在服务B正常释放该锁之前,服务C就已经拿到了这个锁。这种情况可能导致不可预测的错误。
解决的方案: 加锁的时候设置一个随机数,释放锁时需要比较这个随机数是否一致,匹配一致再去释放这个锁。
redis分布式锁不适合用在长时间的任务中。

redis分布式锁实现

分布式锁类似于 "占坑",而 SETNX(SET if Not eXists) 指令就是这样的一个操作:只允许被一个客户端占有,它是一个原子性的操作。SETNX底层源码如下:

// SET/ SETEX/ SETTEX/ SETNX 最底层实现
void setGenericCommand(client *c, int flags, robj *key, robj *val, robj *expire, int unit, robj *ok_reply, robj *abort_reply) {
    long long milliseconds = 0; /* initialized to avoid any harmness warning */

    // 如果定义了 key 的过期时间则保存到上面定义的变量中
    // 如果过期时间设置错误则返回错误信息
    if (expire) {
        if (getLongLongFromObjectOrReply(c, expire, &milliseconds, NULL) != C_OK)
            return;
        if (milliseconds <= 0) {
            addReplyErrorFormat(c,"invalid expire time in %s",c->cmd->name);
            return;
        }
        if (unit == UNIT_SECONDS) milliseconds *= 1000;
    }

    // lookupKeyWrite 函数是为执行写操作而取出 key 的值对象
    // 这里的判断条件是:
    // 1.如果设置了 NX(不存在),并且在数据库中找到了 key 值
    // 2.或者设置了 XX(存在),并且在数据库中没有找到该 key
    // => 那么回复 abort_reply 给客户端
    if ((flags & OBJ_SET_NX && lookupKeyWrite(c->db,key) != NULL) ||
        (flags & OBJ_SET_XX && lookupKeyWrite(c->db,key) == NULL))
    {
        addReply(c, abort_reply ? abort_reply : shared.null[c->resp]);
        return;
    }

    // 在当前的数据库中设置键为 key 值为 value 的数据
    genericSetKey(c->db,key,val,flags & OBJ_SET_KEEPTTL);
    // 服务器每修改一个 key 后都会修改 dirty 值
    server.dirty++;
    if (expire) setExpire(c,c->db,key,mstime()+milliseconds);
    notifyKeyspaceEvent(NOTIFY_STRING,"set",key,c->db->id);
    if (expire) notifyKeyspaceEvent(NOTIFY_GENERIC,
        "expire",key,c->db->id);
    addReply(c, ok_reply ? ok_reply : shared.ok);
}

复制代码

基于redis的SETNX指令的原理,以下是用java实现的带有超时机制和随机值匹配的redis分布锁:

private static final String LOCK_SUCCESS = "OK";
private static final Long RELEASE_SUCCESS = 1L;
private static final String SET_IF_NOT_EXIST = "NX";
private static final String SET_WITH_EXPIRE_TIME = "PX";

@Override
public String acquire() {
    try {
        // 获取锁的超时时间,超过这个时间则放弃获取锁
        long end = System.currentTimeMillis() + acquireTimeout;
        // 随机生成一个 value
        String requireToken = UUID.randomUUID().toString();
        while (System.currentTimeMillis() < end) {
            String result = jedis
                .set(lockKey, requireToken, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
            if (LOCK_SUCCESS.equals(result)) {
                return requireToken;
            }
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
    } catch (Exception e) {
        log.error("acquire lock due to error", e);
    }

    return null;
}

@Override
public boolean release(String identify) {
    if (identify == null) {
        return false;
    }

    String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
    Object result = new Object();
    try {
        result = jedis.eval(script, Collections.singletonList(lockKey),
            Collections.singletonList(identify));
        if (RELEASE_SUCCESS.equals(result)) {
            log.info("release lock success, requestToken:{}", identify);
            return true;
        }
    } catch (Exception e) {
        log.error("release lock due to error", e);
    } finally {
        if (jedis != null) {
            jedis.close();
        }
    }

    log.info("release lock failed, requestToken:{}, result:{}", identify, result);
    return false;
}


复制代码

带有超时机制和随机值匹配的redis分布式锁就能万无一失吗?显然不是,官方提供了一个叫Redlock的方案:Redlock
先Mark 以后再好好探究一下Redlock的原理

分类:
阅读
标签: