Redis分佈式非公平鎖的使用

Posted on by

前言

看瞭很多博客，和資料，這裡隻針對redis做分佈式鎖做一下深入探討，希望對你們有幫助。網上提供瞭很多分佈式鎖的操作，這裡逐一舉例然後評論優缺點及改進方案，希望這樣子能讓當傢更好的理解redis分佈式鎖。

redis分佈式鎖第一版

大傢應該都知道Redis做分佈式鎖無非就是INCR命令或者是SetNx命令，這裡我們采用setnx命令。
操作：setnx key 如果操作成功則代表拿到鎖，如果沒有操作成功則代表沒有拿到鎖。

缺點：如果這個人拿到鎖後宕機瞭怎麼辦，那麼這個鎖就再也不能釋放瞭。

改進：給這個鎖增加一個過期時間，這樣如果有效期過瞭，那麼這個鎖就會自動釋放瞭。

redis分佈式鎖第二版

通過上面所說我們應該對redis分佈式進行改進。
操作： 使用setnx 命令，之後，在EXPIREAT key 30000 這條命令設置key的有效期為30秒。
這裡我們可能會發現，如果要是剛setnx結束之後，要是宕機瞭。怎麼辦？那麼我們為瞭保證原子性，所以jedis提供瞭一個原子操作，set（key，value，nx，30，時間單位）這樣便解決瞭。
缺點：如果這個鎖的時間不夠用怎麼辦，那麼就會導致這個功能鎖不住。假設：A拿到鎖瞭，但是A還沒有執行結束，B又拿到鎖瞭，那麼A執行結束的時候是不是會把B的這個鎖給刪除掉。這樣就導致瞭鎖不住的效果。
改進：我們可以學習樂觀所，給鎖的value值是一個唯一的編號，或者版本號，我們每次對鎖進行操作的時候，就會去驗證這個版本號，還是不是自己的版本號。如果不是瞭就不允許操作瞭。

redis分佈式鎖第三版

通過上面的總結這第三版想必也很簡單瞭。知識多瞭一個唯一值而已。但是加瞭唯一值還是改變不瞭鎖不住的結果，隻是解決瞭幫其他的線程解鎖的問題，那麼要怎麼樣才能鎖得住呢？當時我想到的是給他 時間久一點，後來發現其實再久，也一樣會出現鎖不住的時候，而且太久瞭如果宕機瞭，就會有很長時間機器無法工作，很容易造成線程堆積。

redis分佈式鎖最終版

由上面我們發現一般簡單實用redis做鎖其實是有很多漏洞和bug的，但是有沒有能夠解決這些的呢？當然是有的。
模仿AQS鎖， lock方法執行完之後，執行下面代碼是被鎖的，unlock執行完，釋放鎖。其他線程等待，而不是直接返回錯誤結果。

最終版還是打算先上代碼再說，為瞭方便我把所有的實現都寫在瞭一個類裡面。

 @Autowired
    private RedisTemplate redisTemplate;

    @Autowired
    private RedisUtils redisUtils;

    @Autowired(required = false)
    private ThreadPoolTaskScheduler threadPoolTaskScheduler;

    public final String LOCK_PREFIX = "REDIS_LOCK";

    private final Long LOCK_EXPIRE = 30 * 1000L;

    private final Long OVER_TIME = 10L;

    private Map<String,ScheduledFuture<?> > futureMap = new ConcurrentHashMap<>();

    private Jedis jedis;

    public Lock() {
    }

    private ReentrantLock reentrantLock;

    /**
     * 給線程枷鎖
     *
     * @param key
     */
    public void lock(String key) {
        //自旋獲取鎖
        while (true) {
            if (setLock(key)) {//拿鎖成功
                //獲取鎖後開啟任務
                threadPoolTaskScheduler.schedule(()->{
                    Set<String> keys = scan(LOCK_PREFIX);
                    Iterator<String> iterator = keys.iterator();
                    //遍歷所有的key 延長key的時間
                    while (iterator.hasNext()) {
                        log.info("執行動態定時任務: " + LocalDateTime.now().toLocalTime());
                        redisUtils.expire(key, Long.valueOf(OVER_TIME), TimeUnit.SECONDS);//延長時間（秒）
                    }
                },new Trigger(){
                    @Override
                    public Date nextExecutionTime(TriggerContext triggerContext){
                        return new CronTrigger("0/10 * * * * ?").nextExecutionTime(triggerContext);
                    }
                });
                return;
            }
        }
    }

    /**
     * setnx
     *
     * @param key
     * @return
     */
    public boolean setLock(String key) {
        String lock = LOCK_PREFIX + key;
        return (Boolean) redisTemplate.execute(new RedisCallback<Object>() {
            @Override
            public Object doInRedis(RedisConnection redisConnection) throws DataAccessException {
                long expireAt = System.currentTimeMillis() + LOCK_EXPIRE + 1;
                Boolean acquire = redisConnection.setNX(lock.getBytes(), String.valueOf(expireAt).getBytes());
                if (acquire) {
                    return true;
                } else {
                    byte[] value = redisConnection.get(lock.getBytes());
                    if (Objects.nonNull(value) && value.length > 0) {
                        long expireTime = Long.parseLong(new String(value));
                        if (expireTime < System.currentTimeMillis()) {
                            // 如果鎖已經過期
                            byte[] oldValue = redisConnection.getSet(lock.getBytes(), String.valueOf(System.currentTimeMillis() + LOCK_EXPIRE + 1).getBytes());
                            // 防止死鎖
                            return Long.parseLong(new String(oldValue)) < System.currentTimeMillis();
                        }
                    }
                }
                return false;
            }
        });
    }

    /**
     * 刪除鎖
     *
     * @param key
     */
    public void unlock(String key) {
        String lock = LOCK_PREFIX + key;
        synchronized (this) {
            futureMap.get(lock).cancel(true);//停止任務
            redisTemplate.delete(lock);
        }
    }

    /**
     * 判斷key是否存在
     *
     * @param key 鍵
     * @return true 存在 false不存在
     */
    public boolean hasKey(String key) {
        try {
            return redisTemplate.hasKey(key);
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }

    public Set<String> scan(String key) {
        return (Set<String>) redisTemplate.execute((RedisCallback<Set<String>>) connection -> {
            Set<String> keys = Sets.newHashSet();

            JedisCommands commands = (JedisCommands) connection.getNativeConnection();
            MultiKeyCommands multiKeyCommands = (MultiKeyCommands) commands;

            ScanParams scanParams = new ScanParams();
            scanParams.match("*" + key + "*");
            scanParams.count(1000);
            ScanResult<String> scan = multiKeyCommands.scan("0", scanParams);
            while (null != scan.getStringCursor()) {
                keys.addAll(scan.getResult());
                if (!StringUtils.equals("0", scan.getStringCursor())) {
                    scan = multiKeyCommands.scan(scan.getStringCursor(), scanParams);
                    continue;
                } else {
                    break;
                }
            }

            return keys;
        });
    }

分析：

  • 判斷是否獲取到鎖，獲取到鎖，繼續執行，沒有獲取到鎖，自旋繼續獲取。
  • 獲取到鎖後調度一個任務。每10秒執行一次，並且如果發現所沒有釋放延長10秒。
  • 釋放鎖，刪除掉redis中的key，並結束掉對應的鎖的任務。

加鎖運行原理：

在這裡插入圖片描述

解鎖操作原理：

在這裡插入圖片描述

解鎖操作就比較簡單瞭。但是得為瞭不出必要的麻煩，最好是給停止鎖延時任務，和刪除所 這兩部添加進程鎖，可以使用synchronized，也可以使用AQS lock鎖。

這裡Redis非公平鎖詳解算是結束瞭，後期可能會更新使用Redis，實現公平鎖，謝謝大傢的支持，如果有需要的小夥伴可以直接拿走，希望能給大傢帶來幫助。

在這裡我希望看過文章的小夥伴能夠根絕實現原理自己去實現，這樣可以幫助小夥伴理解非公平鎖機制，和Redis實現非公平，如果不喜歡自己去實現的話，這裡我給大傢推薦一個Redission 這個插件，這個插件是一個Redis鎖的很好的一個實現，大傢可以直接用這個。具體怎麼用就不講解瞭，操作非常簡單。

到此這篇關於Redis分佈式非公平鎖的使用的文章就介紹到這瞭,更多相關Redis分佈式非公平鎖內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：