基于Redis的分布式锁及原子性问题(短视频开发)_Redis

短视频开发，基于redis的分布式锁及原子性问题

用 redis 实现分布式锁

主要应用到的是 setnx key value命令（如果不存在，则设置）

主要要实现两个功能：

1、获取锁（设置一个 key）
2、释放锁（删除 key）
基本思想是执行了 setnx命令的线程获得锁，在完成操作后，需要删除 key，释放锁。

加锁：

@override
public boolean trylock(long timeoutsec) {
    // 获取线程标示
    string threadid = id_prefix + thread.currentthread().getid();
    // 获取锁
    boolean success = stringredistemplate.opsforvalue()
            .setifabsent(key_prefix + name, threadid, timeoutsec, timeunit.seconds);
    return boolean.true.equals(success);
}

释放锁：

@override
public void unlock() {
    // 获取线程标示
    string threadid = id_prefix + thread.currentthread().getid();
    // 获取锁中的标示
    string id = stringredistemplate.opsforvalue().get(key_prefix + name);
    // 释放锁
    stringredistemplate.delete(key_prefix + name);
}

可是这里会存在一个隐患——假设该线程发生阻塞（或者其他问题），一直不释放锁（删除 key）这可怎么办？

为了解决这个问题，我们需要为 key 设计一个超时时间，让它超时失效；但是这个超时时间的长短却不好确定：

1、设置过短，会导致其他线程提前获得锁，引发线程安全问题。
2、设置过长，线程需要额外等待。

锁的误删

超时时间是一个非常不好把握的东西，因为业务线程的阻塞时间是不可预估的，在极端情况下，它总能阻塞到 lock 超时失效，正如上图中的线程1，锁超时释放了，导致线程2也进来了，这时候 lock 是线程2的锁了（key 相同，value不同，value一般是线程唯一标识）；假设这时候，线程1突然不阻塞了，它要释放锁，如果按照刚刚的代码逻辑的话，它会释放掉线程2的锁；线程2的锁被释放掉之后，又会导致其他线程进来（线程3），如此往复。。。

为了解决这个问题，需要在释放锁时多加一个判断，每个线程只释放自己的锁，不能释放别人的锁！

释放锁

@override
public void unlock() {
    // 获取线程标示
    string threadid = id_prefix + thread.currentthread().getid();
    // 获取锁中的标示
    string id = stringredistemplate.opsforvalue().get(key_prefix + name);
    // 判断标示是否一致
    if(threadid.equals(id)) {
        // 释放锁
        stringredistemplate.delete(key_prefix + name);
    }
}

原子性问题

刚刚我们谈论的释放锁的逻辑：

1、判断当前锁是当前线程的锁
2、当前线程释放锁
可以看到释放锁是分两步完成的，如果你是对并发比较有感觉的话，应该一下子就知道这里会存在问题了。

分步执行，并发问题！

假设线程1 已经判断当前锁是它的锁了，正准备释放锁，可偏偏这时候它阻塞了（可能是 full gc 引起的），锁超时失效，线程2来加锁，这时候锁是线程2的了；可是如果线程1这时候醒过来，因为它已经执行了步骤1了的，所以这时候它会直接直接步骤2，释放锁（可是此时的锁不是线程1的了）

其实这就是一个原子性的问题，刚刚释放锁的两步应该是原子的，不可分的！

要使得其满足原子性，则需要在 redis 中使用 lua 脚本了。

引入 lua 脚本保持原子性
lua 脚本：

-- 比较线程标示与锁中的标示是否一致
if(redis.call('get', keys[1]) ==  argv[1]) then
    -- 释放锁 del key
    return redis.call('del', keys[1])
end
return 0

java 中调用执行：

public class simpleredislock implements ilock {

    private string name;
    private stringredistemplate stringredistemplate;

    public simpleredislock(string name, stringredistemplate stringredistemplate) {
        this.name = name;
        this.stringredistemplate = stringredistemplate;
    }

    private static final string key_prefix = "lock:";
    private static final string id_prefix = uuid.randomuuid().tostring(true) + "-";
    private static final defaultredisscript<long> unlock_script;
    static {
        unlock_script = new defaultredisscript<>();
        unlock_script.setlocation(new classpathresource("unlock.lua"));
        unlock_script.setresulttype(long.class);
    }

    @override
    public boolean trylock(long timeoutsec) {
        // 获取线程标示
        string threadid = id_prefix + thread.currentthread().getid();
        // 获取锁
        boolean success = stringredistemplate.opsforvalue()
                .setifabsent(key_prefix + name, threadid, timeoutsec, timeunit.seconds);
        return boolean.true.equals(success);
    }

    @override
    public void unlock() {
        // 调用lua脚本
        stringredistemplate.execute(
                unlock_script,
                collections.singletonlist(key_prefix + name),
                id_prefix + thread.currentthread().getid());
    }
}

到了目前为止，我们设计的 redis 分布式锁已经是生产可用的，相对完善的分布式锁了。

以上就是短视频开发，基于redis的分布式锁及原子性问题，更多内容欢迎关注之后的文章

到此这篇关于短视频开发，基于redis的分布式锁及原子性问题的文章就介绍到这了,更多相关redis的分布式锁内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！