文章有點(diǎn)長并且繞，先來個(gè)圖片緩沖下！

前言

現(xiàn)在的業(yè)務(wù)場(chǎng)景越來越復(fù)雜，使用的架構(gòu)也就越來越復(fù)雜，分布式、高并發(fā)已經(jīng)是業(yè)務(wù)要求的常態(tài)。像騰訊系的不少服務(wù)，還有CDN優(yōu)化、異地多備份等處理。

實(shí)現(xiàn)要點(diǎn)

互斥性，同一時(shí)刻，只能有一個(gè)客戶端持有鎖。

防止死鎖發(fā)生，如果持有鎖的客戶端崩潰沒有主動(dòng)釋放鎖，也要保證鎖可以正常釋放及其他客戶端可以正常加鎖。

加鎖和釋放鎖必須是同一個(gè)客戶端。

容錯(cuò)性，只有redis還有節(jié)點(diǎn)存活，就可以進(jìn)行正常的加鎖解鎖操作。

正確的redis分布式鎖實(shí)現(xiàn)

錯(cuò)誤加鎖方式一

保證互斥和防止死鎖，首先想到的使用redis的setnx命令保證互斥，為了防止死鎖，鎖需要設(shè)置一個(gè)超時(shí)時(shí)間。

????public?static?void?wrongLock(Jedis?jedis,?String?key,?String?uniqueId,?int?expireTime)?{Long?result?=?jedis.setnx(key,?uniqueId);if?(1?==?result)?{//如果該redis實(shí)例崩潰，那就無法設(shè)置過期時(shí)間了jedis.expire(key,?expireTime);}}

在多線程并發(fā)環(huán)境下，任何非原子性的操作，都可能導(dǎo)致問題。這段代碼中，如果設(shè)置過期時(shí)間時(shí)，redis實(shí)例崩潰，就無法設(shè)置過期時(shí)間。如果客戶端沒有正確的釋放鎖，那么該鎖(永遠(yuǎn)不會(huì)過期)，就永遠(yuǎn)不會(huì)被釋放。

錯(cuò)誤加鎖方式二

比較容易想到的就是設(shè)置值和超時(shí)時(shí)間為原子原子操作就可以解決問題。那使用setnx命令，將value設(shè)置為過期時(shí)間不就ok了嗎？

????public?static?boolean?wrongLock(Jedis?jedis,?String?key,?int?expireTime)?{long?expireTs?=?System.currentTimeMillis()?+?expireTime;//?鎖不存在，當(dāng)前線程加鎖成果if?(jedis.setnx(key,?String.valueOf(expireTs))?==?1)?{return?true;}String?value?=?jedis.get(key);//如果當(dāng)前鎖存在,且鎖已過期if?(value?!=?null?&&?NumberUtils.toLong(value)?<?System.currentTimeMillis())?{//鎖過期，設(shè)置新的過期時(shí)間String?oldValue?=?jedis.getSet(key,?String.valueOf(expireTs));if?(oldValue?!=?null?&&?oldValue.equals(value))?{//?多線程并發(fā)下，只有一個(gè)線程會(huì)設(shè)置成功//?設(shè)置成功的這個(gè)線程，key的舊值一定和設(shè)置之前的key的值一致return?true;}}//?其他情況，加鎖失敗return?true;}

乍看之下，沒有什么問題。但仔細(xì)分析，有如下問題：

value設(shè)置為過期時(shí)間，就要求各個(gè)客戶端嚴(yán)格的時(shí)鐘同步，這就需要使用到同步時(shí)鐘。即使有同步時(shí)鐘，分布式的服務(wù)器一般來說時(shí)間肯定是存在少許誤差的。

鎖過期時(shí)，使用 jedis.getSet雖然可以保證只有一個(gè)線程設(shè)置成功，但是不能保證加鎖和解鎖為同一個(gè)客戶端，因?yàn)闆]有標(biāo)志鎖是哪個(gè)客戶端設(shè)置的嘛。

錯(cuò)誤解鎖方式一

直接刪除key

????public?static?void?wrongReleaseLock(Jedis?jedis,?String?key)?{//不是自己加鎖的key，也會(huì)被釋放jedis.del(key);}

簡單粗暴，直接解鎖，但是不是自己加鎖的，也會(huì)被刪除，這好像有點(diǎn)太隨意了吧！

錯(cuò)誤解鎖方式二

判斷自己是不是鎖的持有者，如果是，則只有持有者才可以釋放鎖。

????public?static?void?wrongReleaseLock(Jedis?jedis,?String?key,?String?uniqueId)?{if?(uniqueId.equals(jedis.get(key)))?{//?如果這時(shí)鎖過期自動(dòng)釋放，又被其他線程加鎖，該線程就會(huì)釋放不屬于自己的鎖jedis.del(key);}}

看起來很完美啊，但是如果你判斷的時(shí)候鎖是自己持有的，這時(shí)鎖超時(shí)自動(dòng)釋放了。然后又被其他客戶端重新上鎖，然后當(dāng)前線程執(zhí)行到j(luò)edis.del(key)，這樣這個(gè)線程不就刪除了其他線程上的鎖嘛，好像有點(diǎn)亂套了哦！

正確的加解鎖方式

基本上避免了以上幾種錯(cuò)誤方式之外，就是正確的方式了。要滿足以下幾個(gè)條件：

命令必須保證互斥

設(shè)置的key必須要有過期時(shí)間，防止崩潰時(shí)鎖無法釋放

value使用唯一id標(biāo)志每個(gè)客戶端，保證只有鎖的持有者才可以釋放鎖

加鎖直接使用set命令同時(shí)設(shè)置唯一id和過期時(shí)間；其中解鎖稍微復(fù)雜些，加鎖之后可以返回唯一id，標(biāo)志此鎖是該客戶端鎖擁有；釋放鎖時(shí)要先判斷擁有者是否是自己，然后刪除，這個(gè)需要redis的lua腳本保證兩個(gè)命令的原子性執(zhí)行。

@Slf4j public?class?RedisDistributedLock?{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";//?鎖的超時(shí)時(shí)間private?static?int?EXPIRE_TIME?=?5?*?1000;//?鎖等待時(shí)間private?static?int?WAIT_TIME?=?1?*?1000;private?Jedis?jedis;private?String?key;public?RedisDistributedLock(Jedis?jedis,?String?key)?{this.jedis?=?jedis;this.key?=?key;}//?不斷嘗試加鎖public?String?lock()?{try?{//?超過等待時(shí)間，加鎖失敗long?waitEnd?=?System.currentTimeMillis()?+?WAIT_TIME;String?value?=?UUID.randomUUID().toString();while?(System.currentTimeMillis()?<?waitEnd)?{String?result?=?jedis.set(key,?value,?SET_IF_NOT_EXIST,?SET_WITH_EXPIRE_TIME,?EXPIRE_TIME);if?(LOCK_SUCCESS.equals(result))?{return?value;}try?{Thread.sleep(10);}?catch?(InterruptedException?e)?{Thread.currentThread().interrupt();}}}?catch?(Exception?ex)?{log.error("lock?error",?ex);}return?null;}public?boolean?release(String?value)?{if?(value?==?null)?{return?false;}//?判斷key存在并且刪除key必須是一個(gè)原子操作//?且誰擁有鎖，誰釋放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(key),Collections.singletonList(value));if?(RELEASE_SUCCESS.equals(result))?{log.info("release?lock?success,?value:{}",?value);return?true;}}?catch?(Exception?e)?{log.error("release?lock?error",?e);}?finally?{if?(jedis?!=?null)?{jedis.close();}}log.info("release?lock?failed,?value:{},?result:{}",?value,?result);return?false;} }

單是一個(gè)redis的分布式鎖就有這么多道道，不知道你是否看明白了？留言討論下吧！

有道無術(shù)，術(shù)可成；有術(shù)無道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??

總結(jié)

以上是生活随笔為你收集整理的​Redis分布式锁，你真的用对了吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。