2. 程式人生 > >使用Redis實現分散式鎖及其優化

使用Redis實現分散式鎖及其優化

阿新 • • 發佈：2019-01-30

目前實現分散式鎖的方式主要有資料庫、Redis和Zookeeper三種，本文主要闡述利用Redis的相關命令來實現分散式鎖。

相關Redis命令

SETNX

如果當前中沒有值，則將其設定為並返回1，否則返回0。

EXPIRE

將設定為秒後自動過期。

GETSET

將的值設定為，並返回其原來的舊值。如果原來沒有舊值，則返回nil。

EVAL與EVALSHA

Redis2.6之後支援的功能，可以將一段lua指令碼傳送到Redis伺服器執行。

起——分散式鎖初探

利用SETNX命令的原子性，我們可以簡單的實現一個初步的分散式鎖（這裡原理就不詳述了，直接上虛擬碼）：

booleantryLock(String key, int lockSeconds) {
  if (SETNX key "1" == 1) {
    EXPIRE key lockSeconds
    return true
  } else {
    return false
  }
}
boolean unlock(String key) {
  DEL key
}

tryLock是一個非阻塞的分散式鎖方法，在獲得鎖失敗後會立即返回。如果需要一個阻塞式的鎖方法，可以將tryLock方法包裝為輪詢（以一定的時間間隔來輪詢，這很重要，否則Redis會吃不消！）。

此種方法看似沒有什麼問題，但其實則有一個漏洞：在加鎖的過程中，客戶端順序的向Redis伺服器傳送了SETNX和EXPIRE命令，那麼假設在SETNX命令執行完成之後，在EXPIRE命令發出去之前客戶端發生崩潰（或客戶端與Redis伺服器的網路連線突然斷掉），導致EXPIRE命令沒有得到執行，其他客戶端將會發生永久死鎖！

承——分散式鎖的改進

更新：此方法解鎖存在漏洞，具體見最文後的追加內容。

為解決上面提出的問題，可以在加鎖時在key

中儲存這個鎖過期的時間（當前客戶端時間戳+鎖時間），然後在獲取鎖失敗時，取出value與當前客戶端時間進行比較，如果確定是已經過期的鎖，則可以確認發生了上面描述的錯誤情況，此時可以使用DEL清掉這個key，然後再重新嘗試去獲得這個鎖。可以嗎？當然不可以！如果沒辦法保證DEL操作和下次SETNX操作之間的原子性，則還是會產生一個競態條件，比如這樣：

C1DEL key
C1 SETNX key <expireTime>
C2 DEL key
C2 SETNX key <expireTime>

當Redis伺服器收到這樣的指令序列時，C1和C2的SETNX都同時返回了1，此時C1和C2都認為自己拿到了鎖，這種情況明顯是不符合預期的。

為解決這個問題，Redis的GETSET命令就派上用場了。客戶端可以使用GETSET命令去設定自己的過期時間，然後得到的返回值與之前GET到的返回值進行比較，如果不同，則表示這個過期的鎖被其他客戶端搶佔了（此時GETSET命令其實已經生效，也就是說key中的過期時間已經被修改，不過此誤差很小，可以忽略不計）。

根據上面的分析思路，可以得出一個改進後的分散式鎖，這裡直接給出Java的實現程式碼：

publicclass RedisLock {
    private static final Logger logger =LoggerFactory.getLogger(RedisLock.class);
    private final StringRedisTemplate stringRedisTemplate;
    private final byte[] lockKey;
    public RedisLock(StringRedisTemplate stringRedisTemplate,String lockKey) {
        this.stringRedisTemplate =stringRedisTemplate;
        this.lockKey = lockKey.getBytes();
    }
    private boolean tryLock(RedisConnection conn, intlockSeconds) throws Exception {
        long nowTime =System.currentTimeMillis();
        long expireTime = nowTime + lockSeconds* 1000 + 1000; // 容忍不同伺服器時間有1秒內的誤差
        if (conn.setNX(lockKey,longToBytes(expireTime))) {
           conn.expire(lockKey, lockSeconds);
            return true;
        } else {
            byte[]oldValue = conn.get(lockKey);
            if (oldValue!= null && bytesToLong(oldValue) < nowTime) {
               // 這個鎖已經過期了，可以獲得它
               // PS: 如果setNX和expire之間客戶端發生崩潰，可能會出現這樣的情況
               byte[] oldValue2 = conn.getSet(lockKey, longToBytes(expireTime));
               if (Arrays.equals(oldValue, oldValue2)) {
                   // 獲得了鎖
                   conn.expire(lockKey, lockSeconds);
                   return true;
               } else {
                   // 被別人搶佔了鎖(此時已經修改了lockKey中的值，不過誤差很小可以忽略)
                   return false;
               }
            }
        }
        return false;
    }
    /**
     * 嘗試獲得鎖，成功返回true，如果失敗或異常立即返回false
     *
     * @param lockSeconds 加鎖的時間(秒)，超過這個時間後鎖會自動釋放
     */
    public boolean tryLock(final int lockSeconds) {
        returnstringRedisTemplate.execute(new RedisCallback<Boolean>() {
            @Override
            publicBoolean doInRedis(RedisConnection conn) throws DataAccessException {
               try {
                   return tryLock(conn, lockSeconds);
               } catch (Exception e) {
                   logger.error("tryLock Error", e);
                   return false;
               }
            }
        });
    }
    /**
     * 輪詢的方式去獲得鎖，成功返回true，超過輪詢次數或異常返回false
     *
     * @param lockSeconds      加鎖的時間(秒)，超過這個時間後鎖會自動釋放
     * @param tryIntervalMillis 輪詢的時間間隔(毫秒)
     * @parammaxTryCount       最大的輪詢次數
     */
    public boolean tryLock(final int lockSeconds, final longtryIntervalMillis, final int maxTryCount) {
        return stringRedisTemplate.execute(newRedisCallback<Boolean>() {
            @Override
            publicBoolean doInRedis(RedisConnection conn) throws DataAccessException {
               int tryCount = 0;
               while (true) {
                   if (++tryCount >= maxTryCount) {
                       // 獲取鎖超時
                       return false;
                   }
                   try {
                       if (tryLock(conn, lockSeconds)) {
                           return true;
                       }
                   } catch (Exception e) {
                       logger.error("tryLock Error", e);
                       return false;
                   }
                   try {
                       Thread.sleep(tryIntervalMillis);
                   } catch (InterruptedException e) {
                       logger.error("tryLock interrupted", e);
                       return false;
                   }
               }
            }
        });
    }
    /**
     * 如果加鎖後的操作比較耗時，呼叫方其實可以在unlock前根據時間判斷下鎖是否已經過期
     * 如果已經過期可以不用呼叫，減少一次請求
     */
    public void unlock() {
        stringRedisTemplate.delete(newString(lockKey));
    }
    public byte[] longToBytes(long value) {
        ByteBuffer buffer =ByteBuffer.allocate(Long.SIZE / Byte.SIZE);
        buffer.putLong(value);
        return buffer.array();
    }
    public long bytesToLong(byte[] bytes) {
        if (bytes.length != Long.SIZE /Byte.SIZE) {
            throw newIllegalArgumentException("wrong length of bytes!");
        }
        returnByteBuffer.wrap(bytes).getLong();
    }
}

轉——分散式鎖的優化

更新：此方法解鎖存在漏洞，具體見本後最後的追加內容。

以上的分散式鎖實現邏輯已經較為複雜，涉及到了較多的Redis命令，並使得每一次嘗試加鎖的過程都會有至少2次的Redis命令執行，這也就意味著至少兩次與Redis伺服器的網路通訊。而新增後面複雜邏輯的原因只是因為SETNX與EXPIRE這兩條命令執行的原子性無法得到保證。（有些同學會提到Redis的pipeline特性，此處明顯不適用，因為第二條指令的執行以來與第一條執行的結果，pipeline無法實現）

另外，上面的分散式鎖還有一個問題，那就是伺服器之間時間同步的問題。在分散式場景中，多臺伺服器之間的時間做到同步是非常困難的，所以在程式碼中我加了1秒的時間容錯，但依賴伺服器時間的同步還是可能會不靠譜的。

從Redis 2.6開始，客戶端可以直接向Redis伺服器提交Lua指令碼，也就是說可以直接在Redis伺服器來執行一些較複雜的邏輯，而此指令碼的提交對於客戶端來說是相對原子性的。這恰好解決了我們的問題！

我們可以用一個這樣的lua指令碼來描述加鎖的邏輯（關於指令碼的提交命令和Redis的相關規則可以看https://redis.io/commands/eval）：

if(redis.call('setnx', KEYS[1], ARGV[1]) == 1) then
    redis.call('expire', KEYS[1], tonumber(ARGV[2]))
    return true
else
    return false
end

注意：此指令碼中命令的執行並不是嚴格意義上的原子性，如果其中第二條指令EXPIRE執行失敗，整個指令碼執行會返回錯誤，但是第一條指令SETNX仍然是已經生效的！不過此種情況基本可以認為是Redis伺服器已經崩潰（除非是開發階段就可以排除的引數錯誤之類的問題），那麼鎖的安全性就已經不是這裡可以關注的點了。這裡認為對客戶端來說是相對原子性的就足夠了。

這個簡單的指令碼在Redis伺服器得到執行，並返回是否得到鎖。因為指令碼的提交執行只有一條Redis命令，就避免了上面所說的客戶端異常問題。

使用指令碼優化了鎖的邏輯和效能，這裡給出最終的Java實現程式碼：

publicclass RedisLock {
    private static final Logger logger =LoggerFactory.getLogger(RedisLock.class);
    private final StringRedisTemplate stringRedisTemplate;
    private final String lockKey;
    private final List<String> keys;
    /**
     * 使用指令碼在redis伺服器執行這個邏輯可以在一定程度上保證此操作的原子性
     * （即不會發生客戶端在執行setNX和expire命令之間，發生崩潰或失去與伺服器的連線導致expire沒有得到執行，發生永久死鎖）
     * <p>
     * 除非指令碼在redis伺服器執行時redis伺服器發生崩潰，不過此種情況鎖也會失效
     */
    private static final RedisScript<Boolean>SETNX_AND_EXPIRE_SCRIPT;
    static {
        StringBuilder sb = newStringBuilder();
        sb.append("if(redis.call('setnx', KEYS[1], ARGV[1]) == 1) then\n");
       sb.append("\tredis.call('expire', KEYS[1], tonumber(ARGV[2]))\n");
        sb.append("\treturn true\n");
        sb.append("else\n");
        sb.append("\treturnfalse\n");
        sb.append("end");
        SETNX_AND_EXPIRE_SCRIPT = newRedisScriptImpl<Boolean>(sb.toString(), Boolean.class);
    }
    public RedisLock(StringRedisTemplate stringRedisTemplate,String lockKey) {
        this.stringRedisTemplate =stringRedisTemplate;
        this.lockKey = lockKey;
        this.keys =Collections.singletonList(lockKey);
    }
    private boolean doTryLock(int lockSeconds) throws Exception{
        return stringRedisTemplate.execute(SETNX_AND_EXPIRE_SCRIPT,keys, "1", String.valueOf(lockSeconds));
    }
    /**
     * 嘗試獲得鎖，成功返回true，如果失敗立即返回false
     *
     * @param lockSeconds 加鎖的時間(秒)，超過這個時間後鎖會自動釋放
     */
    public boolean tryLock(int lockSeconds) {
        try {
            returndoTryLock(lockSeconds);
        } catch (Exception e) {
           logger.error("tryLock Error", e);
            returnfalse;
        }
    }
    /**
     * 輪詢的方式去獲得鎖，成功返回true，超過輪詢次數或異常返回false
     *
     * @param lockSeconds      加鎖的時間(秒)，超過這個時間後鎖會自動釋放
     * @param tryIntervalMillis 輪詢的時間間隔(毫秒)
     * @parammaxTryCount       最大的輪詢次數
     */
    public boolean tryLock(final int lockSeconds, final longtryIntervalMillis, final int maxTryCount) {
        int tryCount = 0;
        while (true) {
            if(++tryCount >= maxTryCount) {
               // 獲取鎖超時
               return false;
            }
            try {
               if (doTryLock(lockSeconds)) {
                   return true;
               }
            } catch(Exception e) {
               logger.error("tryLock Error", e);
               return false;
            }
            try {
               Thread.sleep(tryIntervalMillis);
            } catch(InterruptedException e) {
               logger.error("tryLock interrupted", e);
               return false;
            }
        }
    }
    /**
     * 如果加鎖後的操作比較耗時，呼叫方其實可以在unlock前根據時間判斷下鎖是否已經過期
     * 如果已經過期可以不用呼叫，減少一次請求
     */
    public void unlock() {
        stringRedisTemplate.delete(lockKey);
    }
    private static class RedisScriptImpl<T> implementsRedisScript<T> {
        private final String script;
        private final String sha1;
        private final Class<T>resultType;
        public RedisScriptImpl(Stringscript, Class<T> resultType) {
            this.script= script;
            this.sha1 =DigestUtils.sha1DigestAsHex(script);
           this.resultType = resultType;
        }
        @Override
        public String getSha1() {
            return sha1;
        }
        @Override
        public Class<T>getResultType() {
            returnresultType;
        }
        @Override
        public String getScriptAsString() {
            returnscript;
        }
    }
}

合——小節

最後，此文內容只是筆者自己學習折騰出來的結果，如果還有什麼筆者沒有考慮到的bug存在，還請不吝指出，大家一起學習進步～

追——解鎖漏洞（更新）

經過慎重考慮，發現以上實現的分散式鎖有一個較為嚴重的解鎖漏洞：因為解鎖操作只是做了簡單的DEL KEY，如果某客戶端在獲得鎖後執行業務的時間超過了鎖的過期時間，則最後的解鎖操作會誤解掉其他客戶端的操作。

為解決此問題，我們在建立RedisLock物件時用本機時間戳和UUID來建立一個絕對唯一的lockValue，然後在加鎖時存入此值，並在解鎖前用GET取出值進行比較，如果匹配才做DEL。這裡依然需要用LUA指令碼保證整個解鎖過程的原子性。

這裡給出修復此漏洞並做了一些小優化之後的程式碼：

importjava.util.Collections;
import java.util.UUID;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.data.redis.core.script.DigestUtils;
import org.springframework.data.redis.core.script.RedisScript;
/**
 * Created On 10/24 2017
 * Redis實現的分散式鎖(不可重入)
 * 此物件非執行緒安全，使用時務必注意
 */
public class RedisLock {
    private static final Logger logger =LoggerFactory.getLogger(RedisLock.class);
    private final StringRedisTemplate stringRedisTemplate;
    private final String lockKey;
    private final String lockValue;
    private boolean locked = false;
    /**
     * 使用指令碼在redis伺服器執行這個邏輯可以在一定程度上保證此操作的原子性
     * （即不會發生客戶端在執行setNX和expire命令之間，發生崩潰或失去與伺服器的連線導致expire沒有得到執行，發生永久死鎖）
     * <p>
     * 除非指令碼在redis伺服器執行時redis伺服器發生崩潰，不過此種情況鎖也會失效
     */
    private static final RedisScript<Boolean>SETNX_AND_EXPIRE_SCRIPT;
    static {
        StringBuilder sb = newStringBuilder();
        sb.append("if (redis.call('setnx',KEYS[1], ARGV[1]) == 1) then\n");
       sb.append("\tredis.call('expire', KEYS[1], tonumber(ARGV[2]))\n");
        sb.append("\treturntrue\n");
        sb.append("else\n");
        sb.append("\treturnfalse\n");
        sb.append("end");
        SETNX_AND_EXPIRE_SCRIPT = newRedisScriptImpl<Boolean>(sb.toString(), Boolean.class);
    }
    private static final RedisScript<Boolean>DEL_IF_GET_EQUALS;
    static {
        StringBuilder sb = newStringBuilder();
        sb.append("if (redis.call('get',KEYS[1]) == ARGV[1]) then\n");
        sb.append("\tredis.call('del',KEYS[1])\n");
        sb.append("\treturntrue\n");
        sb.append("else\n");
        sb.append("\treturnfalse\n");
        sb.append("end");
        DEL_IF_GET_EQUALS = newRedisScriptImpl<Boolean>(sb.toString(), Boolean.class);
    }
    public RedisLock(StringRedisTemplate stringRedisTemplate,String lockKey) {
        this.stringRedisTemplate =stringRedisTemplate;
        this.lockKey = lockKey;
        this.lockValue =UUID.randomUUID().toString() + "." + System.currentTimeMillis();
    }
    private boolean doTryLock(int lockSeconds) throws Exception{
        if (locked) {
            throw newIllegalStateException("already locked!");
        }
        locked = stringRedisTemplate.execute(SETNX_AND_EXPIRE_SCRIPT,Collections.singletonList(lockKey), lockValue,
                                            String.valueOf(lockSeconds));
        return locked;
    }
    /**
     * 嘗試獲得鎖，成功返回true，如果失敗立即返回false
     *
     * @param lockSeconds 加鎖的時間(秒)，超過這個時間後鎖會自動釋放
     */
    public boolean tryLock(int lockSeconds) {
        try {
            returndoTryLock(lockSeconds);
        } catch (Exception e) {
           logger.error("tryLock Error", e);
            return false;
        }
    }
    /**
     * 輪詢的方式去獲得鎖，成功返回true，超過輪詢次數或異常返回false
     *
     * @paramlockSeconds       加鎖的時間(秒)，超過這個時間後鎖會自動釋放
     * @param tryIntervalMillis 輪詢的時間間隔(毫秒)
     * @parammaxTryCount       最大的輪詢次數
     */
    public boolean tryLock(final int lockSeconds, final longtryIntervalMillis, final int maxTryCount) {
        int tryCount = 0;
        while (true) {
            if(++tryCount >= maxTryCount) {
               // 獲取鎖超時
               return false;
            }
            try {
               if (doTryLock(lockSeconds)) {
                   return true;
               }
            } catch(Exception e) {
               logger.error("tryLock Error", e);
               return false;
            }
            try {
               Thread.sleep(tryIntervalMillis);
            } catch(InterruptedException e) {
               logger.error("tryLock interrupted", e);
               return false;
            }
        }
    }
    /**
     * 解鎖操作
     */
    public void unlock() {
        if (!locked) {
            throw newIllegalStateException("not locked yet!");
        }
        locked = false;
        // 忽略結果
       stringRedisTemplate.execute(DEL_IF_GET_EQUALS,Collections.singletonList(lockKey), lockValue);
    }
    private static class RedisScriptImpl<T> implementsRedisScript<T> {
        private final String script;
        private final String sha1;
        private final Class<T>resultType;
        public RedisScriptImpl(Stringscript, Class<T> resultType) {
            this.script= script;
            this.sha1 =DigestUtils.sha1DigestAsHex(script);
           this.resultType = resultType;
        }
        @Override
        public String getSha1() {
            return sha1;
        }
        @Override
        public Class<T>getResultType() {
            returnresultType;
        }
        @Override
        public String getScriptAsString() {
            returnscript;
        }
    }
}

出處：http://mzorro.me/2017/10/25/redis-distributed-lock/

相關推薦

使用Redis實現分散式鎖及其優化

目前實現分散式鎖的方式主要有資料庫、Redis和Zookeeper三種，本文主要闡述利用Redis的相關命令來實現分散式鎖。 相關Redis命令 SETNX 如果當前中沒有值，則將其設定為並返回1，否則返回0。 EXPIRE 將設定為秒後自動過期。 GETSET 將的值設

【redis】使用redisTemplate優雅地操作redis及使用redis實現分散式鎖

前言: 上篇已經介紹了redis及如何安裝和叢集redis,這篇介紹如何通過工具優雅地操作redis. Long Long ago,程式猿們還在通過jedis來操作著redis,那時候的猿類,一個個累的沒日沒夜,重複的造著輪子,忙得沒時間陪家人,終於有一天猿類的春天來了,spring家族的r

利用Redisson實現分散式鎖及其底層原理解析

Redis介紹 redis是一個key-value儲存系統。和Memcached類似，它支援儲存的value型別相對更多，包括string(字串)、list(連結串列)、set(集合)、zset(sorted set --有序集合)和hash（雜湊型別）。這些資料型別都支援push/po

基於Redis實現分散式鎖

背景 在很多網際網路產品應用中，有些場景需要加鎖處理，比如：秒殺，全域性遞增ID，樓層生成等等。大部分的解決方案是基於DB實現的，Redis為單程序單執行緒模式，採用佇列模式將併發訪問變成序列訪問，且多客戶端對Redis的連線並不存在競爭關係。其次Redis提供一些命令SETNX，GETSET，可以方便

利用Redis實現分散式鎖 使用mysql樂觀鎖解決併發問題

寫在最前面 我在之前總結冪等性的時候，寫過一種分散式鎖的實現，可惜當時沒有真正應用過，著實的心虛啊。正好這段時間對這部分實踐了一下，也算是對之前填坑了。 分散式鎖按照網上的結論，大致分為三種：1、資料庫樂觀鎖； 2、基於Redis的分散式鎖；3.、基於ZooKeeper的分散式鎖； 關於樂觀鎖的實現其實

利用Redis實現分散式鎖

為什麼需要分散式鎖？ 在傳統單體應用單機部署的情況下，可以使用Java併發相關的鎖，如ReentrantLcok或synchronized進行互斥控制。但是，隨著業務發展的需要，原單體單機部署的系統，漸漸的被部署在多機器多JVM上同時提供服務，這使得原單機部署情況下的併發控制鎖策略失效了，為了解決這個問

如何用 Redis 實現分散式鎖和超時情況處理

目前各種分散式的架構和微服務架構無處不在，在這種類似架構中處理併發和分散式併發問題，本場 Chat 就主要以 Redis 為例，使用分散式鎖的方式如何處理併發問題和避免超時情況的出現，主要從以下幾個方面講述： Redis 的 Setnx 命令是如何實現分散式鎖的； Setnx 的實現鎖的

ZooKeeper分散式鎖簡單實踐 利用Redis實現分散式鎖

寫在最前面 前幾周寫了篇 利用Redis實現分散式鎖 ，今天簡單總結下ZooKeeper實現分散式鎖的過程。其實生產上我只用過Redis或者資料庫的方式，之前還真沒了解過ZooKeeper怎麼實現分散式鎖。這周簡單寫了個小Demo，更堅定了我繼續使用Redis的信心了。 ZooKeep

分散式鎖-使用Redis實現分散式鎖

使用Redis實現分散式鎖 關於分散式鎖的實現，我的前一篇文章講解了如何使用Zookeeper實現分散式鎖。關於分散式鎖的背景此處不再做贅述，我們直接討論下如何使用Redis實現分散式鎖。 關於Redis，筆主不打算做長篇大論的介紹，只介紹下Redis優秀的特性

REDIS 學習（10）流程圖解使用redis實現分散式鎖

redis作為集中式快取，可以通過它來實現分散式鎖。 首先用到的redis操作有： setnx key value:      當key不存在的時候生效並返回1，當已經有此key的時候返回0 getset key value:    

RedLock演算法-使用redis實現分散式鎖服務

譯自Redis官方文件 在多執行緒共享臨界資源的場景下，分散式鎖是一種非常重要的元件。 許多庫使用不同的方式使用redis實現一個分散式鎖管理。 其中有一部分簡單的實現方式可靠性不足，可以通過一些簡單的修改提高其可靠性。 這篇文章介紹了一種指導性的redis分散式鎖演算法RedLock，RedL

Redis實現分散式鎖（spring定時任務叢集應用Redis分散式鎖）

         之前2片文章介紹了 描述：              不管用不用動態執行，單機服務都是沒有問題的，但是如果服務是叢集模式下，那麼一個任務在每臺機器都會執行一次，這肯定不是我們需要的，我們要實現的是整個叢集每次只有一個任務執行成功，但是spring

【Redis實現分散式鎖】Redis實現分散式鎖

前言 分散式鎖一般有三種實現方式：1. 資料庫樂觀鎖；2. 基於Redis的分散式鎖；3. 基於ZooKeeper的分散式鎖。本篇部落格將介紹第二種方式，基於Redis實現分散式鎖。雖然網上已經有各種介紹Redis分散式鎖實現的部落格，然而他們的實現卻有著各種各樣的問題，為

使用redis實現分散式鎖

大致思路： 加鎖： 利用set方法的nx,px引數: nx引數表示當key不存在時才成功,key存在時失敗，故保證了排他性. px引數表示設定過期時間,保證了執行緒出現異常無法釋放鎖(刪除key) 釋放鎖： 不能簡單地刪除鍵，因為可能出現這樣的情況:執行緒成功se

Redis實現分散式鎖機制

Redis實現分散式鎖思路 　　常用的是redis函式是setnx()，這個應該是實現分散式鎖最主要的函式。首先是將某一業務標識名作為鍵存到redis裡，併為其設個過期時間，如果是還有加鎖請求過來，先是通過setnx()看看是否能將鎖的標識插入到redis裡，可

基於 Redis 實現分散式鎖

什麼是Redis？ Redis通常被稱為資料結構伺服器。這意味著Redis通過一組命令提供對可變資料結構的訪問，這些命令使用帶有TCP套接字和簡單協議的伺服器 - 客戶端模型傳送。因此，不同的程序可以以共享方式查詢和修改相同的資料結構。 Redis中實現的資料結構有一些特殊屬性：

redis實現分散式鎖（基於lua指令碼操作）

lua指令碼能保證redis的原子性操作，redis使用springboot的redistemplate /** * create by abel * create date 2018/11/16 11:28 * describe:請輸入專案描述 */ public class

什麼是分散式鎖？Redis實現分散式鎖詳解

　　   　　在很多場景中，我們為了保證資料的最終一致性，需要很多的技術方案來支援，比如分散式事務、分散式鎖等。那具體什麼是分散式鎖，分散式鎖應用在哪些業務場景、如何來實現分散式鎖呢?今天繼續由陳睿|mikechen來繼續分享Redis這個系列。 　　01.什麼是分散式鎖

redis實現分散式鎖

/** * 分散式鎖的簡單實現程式碼 */ public class DistributedLock { private final JedisPool jedisPool; public DistributedLock(JedisPool

Redis實現分散式鎖與任務佇列的思路

一, 實現思路 1.Redis實現分散式鎖思路 思路很簡單，主要用到的redis函式是setnx()，這個應該是實現分散式鎖最主要的函式。首先是將某一任務標識名（這裡用Lock:order作為標識名的例子）作為鍵存到redis裡，併為其設個過期時間，如果是還有Lock:order請求過來，先