.jpg)
分布式鎖一般有三種實(shí)現(xiàn)方式：1. 數(shù)據(jù)庫(kù)樂(lè)觀鎖；2. 基于redis的分布式鎖；3. 基于zookeeper的分布式鎖。
這里介紹基于redis實(shí)現(xiàn)分布式鎖。
分布式鎖的性質(zhì)：
可靠性。首先，為了確保分布式鎖可用，我們至少要確保鎖的實(shí)現(xiàn)同時(shí)滿足以下四個(gè)條件：
互斥性。在任意時(shí)刻，只有一個(gè)客戶端能持有鎖。
不會(huì)發(fā)生死鎖。即使有一個(gè)客戶端在持有鎖的期間崩潰而沒(méi)有主動(dòng)解鎖，也能保證后續(xù)其他客戶端能加鎖。
具有容錯(cuò)性。只要大部分的Redis節(jié)點(diǎn)正常運(yùn)行，客戶端就可以加鎖和解鎖。
解鈴還須系鈴人。加鎖和解鎖必須是同一個(gè)客戶端，客戶端自己不能把別人加的鎖給解了。
代碼實(shí)現(xiàn) 組件依賴
首先我們要通過(guò)maven引入Jedis開源組件，在pom.xml文件加入下面的代碼：
<dependency> ????<groupid>redis.clients</groupid> ????<artifactid>jedis</artifactid> ????<version>2.9.0</version></dependency>
?
加鎖代碼 正確姿勢(shì)
Talk is cheap, show me the code。先展示代碼，再帶大家慢慢解釋為什么這樣實(shí)現(xiàn)：
public?class?RedisTool?{ ????private?static?final?String?LOCK_SUCCESS?=?"OK"; ????private?static?final?String?SET_IF_NOT_EXIST?=?"NX"; ????private?static?final?String?SET_WITH_EXPIRE_TIME?=?"PX"; ????/** ?????*?嘗試獲取分布式鎖 ?????*?@param?jedis?Redis客戶端 ?????*?@param?lockKey?鎖 ?????*?@param?requestId?請(qǐng)求標(biāo)識(shí) ?????*?@param?expireTime?超期時(shí)間 ?????*?@return?是否獲取成功 ?????*/ ????public?static?boolean?tryGetDistributedLock(Jedis?jedis,?String?lockKey,?String?requestId,?int?expireTime)?{ ????????String?result?=?jedis.set(lockKey,?requestId,?SET_IF_NOT_EXIST,?SET_WITH_EXPIRE_TIME,?expireTime); ????????if?(LOCK_SUCCESS.equals(result))?{ ????????????return?true; ????????} ????????return?false; ????} }
可以看到，我們加鎖就一行代碼：jedis.set(String key, String value, String nxxx, String expx, int time)，這個(gè)set()方法一共有五個(gè)形參：
第一個(gè)為key，我們使用key來(lái)當(dāng)鎖，因?yàn)閗ey是唯一的。
第二個(gè)為value，我們傳的是requestId，很多童鞋可能不明白，有key作為鎖不就夠了嗎，為什么還要用到value？原因就是我們?cè)谏厦嬷v到可靠性時(shí)，分布式鎖要滿足第四個(gè)條件解鈴還須系鈴人，通過(guò)給value賦值為requestId，我們就知道這把鎖是哪個(gè)請(qǐng)求加的了，在解鎖的時(shí)候就可以有依據(jù)。requestId可以使用UUID.randomUUID().toString()方法生成。
第三個(gè)為nxxx，這個(gè)參數(shù)我們填的是NX，意思是SET IF NOT EXIST，即當(dāng)key不存在時(shí)，我們進(jìn)行set操作；若key已經(jīng)存在，則不做任何操作；
第四個(gè)為expx，這個(gè)參數(shù)我們傳的是PX，意思是我們要給這個(gè)key加一個(gè)過(guò)期的設(shè)置，具體時(shí)間由第五個(gè)參數(shù)決定。
第五個(gè)為time，與第四個(gè)參數(shù)相呼應(yīng)，代表key的過(guò)期時(shí)間。
總的來(lái)說(shuō)，執(zhí)行上面的set()方法就只會(huì)導(dǎo)致兩種結(jié)果：1. 當(dāng)前沒(méi)有鎖（key不存在），那么就進(jìn)行加鎖操作，并對(duì)鎖設(shè)置個(gè)有效期，同時(shí)value表示加鎖的客戶端。2. 已有鎖存在，不做任何操作。
我們的加鎖代碼滿足我們可靠性里描述的三個(gè)條件。首先，set()加入了NX參數(shù)，可以保證如果已有key存在，則函數(shù)不會(huì)調(diào)用成功，也就是只有一個(gè)客戶端能持有鎖，滿足互斥性。其次，由于我們對(duì)鎖設(shè)置了過(guò)期時(shí)間，即使鎖的持有者后續(xù)發(fā)生崩潰而沒(méi)有解鎖，鎖也會(huì)因?yàn)榈搅诉^(guò)期時(shí)間而自動(dòng)解鎖（即key被刪除），不會(huì)發(fā)生死鎖。最后，因?yàn)槲覀儗alue賦值為requestId，代表加鎖的客戶端請(qǐng)求標(biāo)識(shí)，那么在客戶端在解鎖的時(shí)候就可以進(jìn)行校驗(yàn)是否是同一個(gè)客戶端。由于我們只考慮Redis單機(jī)部署的場(chǎng)景，所以容錯(cuò)性我們暫不考慮。
.png)
