一、為什么要使用分布式鎖？
我們?cè)陂_發(fā)應(yīng)用的時(shí)候，如果需要對(duì)某一個(gè)共享變量進(jìn)行多線程同步訪問的時(shí)候，可以使用我們學(xué)到的Java多線程的18般武藝進(jìn)行處理，并且可以完美的運(yùn)行，毫無Bug！
注意這是單機(jī)應(yīng)用，也就是所有的請(qǐng)求都會(huì)分配到當(dāng)前服務(wù)器的JVM內(nèi)部，然后映射為操作系統(tǒng)的線程進(jìn)行處理！而這個(gè)共享變量只是在這個(gè)JVM內(nèi)部的一塊內(nèi)存空間！
后來業(yè)務(wù)發(fā)展，需要做集群，一個(gè)應(yīng)用需要部署到幾臺(tái)機(jī)器上然后做負(fù)載均衡，大致如下圖：
上圖可以看到，變量A存在JVM1、JVM2、JVM3三個(gè)JVM內(nèi)存中（這個(gè)變量A主要體現(xiàn)是在一個(gè)類中的一個(gè)成員變量，是一個(gè)有狀態(tài)的對(duì)象，例如：UserController控制器中的一個(gè)整形類型的成員變量），如果不加任何控制的話，變量A同時(shí)都會(huì)在JVM分配一塊內(nèi)存，三個(gè)請(qǐng)求發(fā)過來同時(shí)對(duì)這個(gè)變量操作，顯然結(jié)果是不對(duì)的！即使不是同時(shí)發(fā)過來，三個(gè)請(qǐng)求分別操作三個(gè)不同JVM內(nèi)存區(qū)域的數(shù)據(jù)，變量A之間不存在共享，也不具有可見性，處理的結(jié)果也是不對(duì)的！
如果我們業(yè)務(wù)中確實(shí)存在這個(gè)場(chǎng)景的話，我們就需要一種方法解決這個(gè)問題！
為了保證一個(gè)方法或?qū)傩栽诟卟l(fā)情況下的同一時(shí)間只能被同一線程執(zhí)行，在傳統(tǒng)單體應(yīng)用單機(jī)部署的情況下，可以使用java并發(fā)處理相關(guān)的API（如 ReentrantLock或Synchronized ）進(jìn)行互斥控制。但是，隨著業(yè)務(wù)發(fā)展的需要，原單體單機(jī)部署的系統(tǒng)被演化成分布式集群系統(tǒng)后，由于分布式系統(tǒng)多線程、多進(jìn)程并且分布在不同機(jī)器上，這將使原單機(jī)部署情況下的并發(fā)控制鎖策略失效，單純的java API并不能提供分布式鎖的能力，為了解決這個(gè)問題就需要一種跨JVM的互斥機(jī)制來控制共享資源的訪問，這就是分布式鎖要解決的問題。
二、分布式鎖應(yīng)具備哪些條件
1、在分布式系統(tǒng)環(huán)境下，一個(gè)方法在同一時(shí)間只能被一個(gè)機(jī)器的一個(gè)線程執(zhí)行；
2、高可用、高性能的獲取鎖與釋放鎖；
3、具備可重入特性；
4、具備鎖失效機(jī)制，防止死鎖；
5、具備非阻塞鎖特性，即沒有獲取到鎖將直接返回獲取鎖失敗。
三、分布式鎖的三種實(shí)現(xiàn)方式
目前幾乎很多大型網(wǎng)站及應(yīng)用都是分布式部署的，分布式場(chǎng)景中的數(shù)據(jù)一致性問題一直是一個(gè)比較重要的話題。分布式的CAP理論告訴我們“任何一個(gè)分布式系統(tǒng)都無法同時(shí)滿足一致性、可用性和分區(qū)容錯(cuò)性，最多只能滿足兩項(xiàng)?！彼裕芏嘞到y(tǒng)在設(shè)計(jì)之初就要對(duì)這三者進(jìn)行取舍。在互聯(lián)網(wǎng)領(lǐng)域的絕大多數(shù)的場(chǎng)景中，都需要犧牲掉一致性來換取系統(tǒng)的高可用性，系統(tǒng)往往只需要保證最終一致性，只要這個(gè)最終時(shí)間是在用戶可以接受的范圍內(nèi)即可。
在很多場(chǎng)景中，為了保證數(shù)據(jù)的最終一致性，需要很多的技術(shù)方案來支持，比如分布式事務(wù)、分布式鎖等。
分布式鎖的三種實(shí)現(xiàn)方式：
1、基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖；
2、基于緩存（Redis）實(shí)現(xiàn)分布式鎖；
3、基于Zookeeper實(shí)現(xiàn)分布式；
盡管有這三種方案，但是不同的業(yè)務(wù)也要根據(jù)自己的情況進(jìn)行選型，他們之間沒有最好只有更適合！
四、基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖
基于數(shù)據(jù)庫的實(shí)現(xiàn)方式的核心思想是：在數(shù)據(jù)庫中創(chuàng)建一個(gè)表，表中包含方法名等字段，并在方法名字段上創(chuàng)建唯一索引，想要執(zhí)行某個(gè)方法，就使用這個(gè)方法名向表中插入數(shù)據(jù)，成功插入則獲取鎖，執(zhí)行完成后刪除對(duì)應(yīng)的行數(shù)據(jù)釋放鎖。
1、創(chuàng)建一個(gè)表
DROP?TABLE?IF?EXISTS?`method_lock`;??
CREATE?TABLE?`method_lock`?(??
??`id`?int(11)?unsigned?NOT?NULL?AUTO_INCREMENT?COMMENT?'主鍵',??
??`method_name`?varchar(64)?NOT?NULL?COMMENT?'鎖定的方法名',??
??`desc`?varchar(255)?NOT?NULL?COMMENT?'備注信息',??
??`update_time`?timestamp?NOT?NULL?DEFAULT?CURRENT_TIMESTAMP?ON?UPDATE?CURRENT_TIMESTAMP,??
??PRIMARY?KEY?(`id`),??
??UNIQUE?KEY?`uidx_method_name`?(`method_name`)?USING?BTREE??
)ENGINE=InnoDB?AUTO_INCREMENT=3?DEFAULT?CHARSET=utf8?COMMENT='鎖定中的方法';?
2、想要執(zhí)行某個(gè)方法，就要使用這個(gè)方法名向表中插入數(shù)據(jù)
INSERT?INTO?method_lock?(method_name,?desc)?VALUES?('methodName',?'測(cè)試的methodName');?
因?yàn)槲覀儗?duì)method_name做了唯一性約束，這里如果有多個(gè)請(qǐng)求同時(shí)提交到數(shù)據(jù)庫的話，數(shù)據(jù)庫會(huì)保證只有一個(gè)操作可以成功，那么我們就可以認(rèn)為操作成功的那個(gè)線程獲得了該方法的鎖，可以執(zhí)行方法體內(nèi)容。
3、成功插入則獲取鎖，執(zhí)行完畢后刪除對(duì)應(yīng)的行數(shù)據(jù)釋放鎖
delete?from?method_lock?where?method_name?='methodName';?
注意：這只是使用基于數(shù)據(jù)庫的一種方法，使用數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖還有很多其它的方法。
4、存在的一些問題
（1）因?yàn)槭腔跀?shù)據(jù)庫實(shí)現(xiàn)的，數(shù)據(jù)庫的高可用性和性能將直接影響分布式鎖的可用性和性能，所以，數(shù)據(jù)庫需要雙機(jī)熱備、數(shù)據(jù)同步、準(zhǔn)備切換。
（2）不具備可重入的特性，因?yàn)橥痪€程在釋放鎖之前，行數(shù)據(jù)一直存在，無法再次成功插入數(shù)據(jù)，所以，需要在表中新增一列，用于記錄當(dāng)前獲取到鎖的機(jī)器和線程信息，在再次獲取鎖的時(shí)候，先查詢表中機(jī)器和線程信息是否是當(dāng)前機(jī)器和線程，若相同則直接獲取鎖。
（3）沒有鎖失效機(jī)制，因?yàn)橛锌赡艹霈F(xiàn)成功插入數(shù)據(jù)后，服務(wù)器宕機(jī)了，對(duì)應(yīng)的數(shù)據(jù)沒有被刪除，當(dāng)服務(wù)恢復(fù)后一直獲取不到鎖，所以，需要在表中新增一列，用于記錄失效時(shí)間，并且需要定時(shí)消除這些失效的數(shù)據(jù)。
（4）不具備阻塞鎖特性，獲取不到鎖直接返回失敗，所以需要優(yōu)化獲取邏輯，循環(huán)多次去獲取。
（5）在實(shí)施的過程中遇到各種不同的問題，為了解決這些問題，實(shí)現(xiàn)方式將越來越復(fù)雜，依賴數(shù)據(jù)庫需要一定的資源開銷，性能問題需要考慮。
五、基于緩存（Redis）實(shí)現(xiàn)分布式鎖
1、使用Redis實(shí)現(xiàn)分布式鎖原因：
（1）Redis有很高的性能；
（2）Redis命令對(duì)此支持較好，實(shí)現(xiàn)起來比較方便
2、使用命令簡(jiǎn)介
（1） setnx
SETNX key val：當(dāng)key不存在時(shí)，set一個(gè)key為val的字符串，返回1；若key存在，則什么都不做，返回0。
（2）expire
expire key timeout：為key設(shè)置一個(gè)超時(shí)時(shí)間，單位是秒，超過這個(gè)時(shí)間鎖會(huì)自動(dòng)釋放，避免死鎖。
（3）delete
刪除key。
3、實(shí)現(xiàn)思想
（1）獲取鎖的時(shí)候，使用 setnx 加鎖，并使用expire命令為鎖添加一個(gè)超時(shí)時(shí)間，超過該時(shí)間則自動(dòng)釋放鎖，鎖的值為一個(gè)隨機(jī)生成的UUID，通過此在釋放鎖的時(shí)候進(jìn)行判斷。
（2）獲取鎖的時(shí)候還設(shè)置了一個(gè)獲取的超時(shí)時(shí)間，若超過這個(gè)時(shí)間則放棄獲取鎖。
（3）釋放鎖的時(shí)候，通過UUID判斷是不是該鎖，若是該鎖，則執(zhí)行delete進(jìn)行鎖釋放。
4、分布式鎖的簡(jiǎn)單代碼
/**??
?*?分布式鎖的簡(jiǎn)單實(shí)現(xiàn)代碼??
?*?Created?by?素小暖?on?2020/2/12.??
?*/??
public?class?DistributedLock?{??
????private?final?JedisPool?jedisPool;??
????public?DistributedLock(JedisPool?jedisPool)?{??
this.jedisPool?=?jedisPool;??
????}??
????/**??
?????*?加鎖??
?????*?@param?lockName???????鎖的key??
?????*?@param?acquireTimeout?獲取超時(shí)時(shí)間??
?????*?@param?timeout????????鎖的超時(shí)時(shí)間??
?????*?@return?鎖標(biāo)識(shí)??
?????*/??
????public?String?lockWithTimeout(String?lockName,?long?acquireTimeout,?long?timeout)?{??
Jedisconn?=?null;??
StringretIdentifier?=?null;??
????????try?{??
????????????//?獲取連接??
conn?=?jedisPool.getResource();??
????????????//?隨機(jī)生成一個(gè)value??
Stringidentifier?=?UUID.randomUUID().toString();??
????????????//?鎖名，即key值??
StringlockKey?=?"lock:"?+?lockName;??
????????????//?超時(shí)時(shí)間，上鎖后超過此時(shí)間則自動(dòng)釋放鎖??
intlockExpire?=?(int)?(timeout?/?1000);??
????????????//?獲取鎖的超時(shí)時(shí)間，超過這個(gè)時(shí)間則放棄獲取鎖??
longend?=?System.currentTimeMillis()?+?acquireTimeout;??
while?(System.currentTimeMillis()<?end)?{??
????????????????if?(conn.setnx(lockKey,?identifier)?==?1)?{??
????????????????????conn.expire(lockKey,?lockExpire);??
????????????????????//?返回value值，用于釋放鎖時(shí)間確認(rèn)??
retIdentifier?=?identifier;??
????????????????????return?retIdentifier;??
????????????????}??
????????????????//?返回-1代表key沒有設(shè)置超時(shí)時(shí)間，為key設(shè)置一個(gè)超時(shí)時(shí)間??
????????????????if?(conn.ttl(lockKey)?==?-1)?{??
????????????????????conn.expire(lockKey,?lockExpire);??
????????????????}??
????????????????try?{??
????????????????????Thread.sleep(10);??
????????????????}?catch?(InterruptedException?e)?{??
????????????????????Thread.currentThread().interrupt();?
????????????????}??
????????????}??
????????}?catch?(JedisException?e)?{??
????????????e.printStackTrace();??
????????}?finally?{??
????????????if?(conn?!=?null)?{??
????????????????conn.close();??
????????????}??
????????}??
????????return?retIdentifier;??
????}??
????/**??
?????*?釋放鎖??
?????*?@param?lockName???鎖的key??
?????*?@param?identifier?釋放鎖的標(biāo)識(shí)??
?????*?@return??
?????*/??
????public?boolean?releaseLock(String?lockName,?String?identifier)?{??
Jedisconn?=?null;?
StringlockKey?=?"lock:"?+?lockName;??
booleanretFlag?=?false;??
????????try?{??
conn?=?jedisPool.getResource();??
????????????while?(true)?{??
????????????????//?監(jiān)視lock，準(zhǔn)備開始事務(wù)??
????????????????conn.watch(lockKey);??
????????????????//?通過前面返回的value值判斷是不是該鎖，若是該鎖，則刪除，釋放鎖??
????????????????if?(identifier.equals(conn.get(lockKey)))?{??
Transactiontransaction?=?conn.multi();??
????????????????????transaction.del(lockKey);??
List<Object>?results?=?transaction.exec();??
if?(results?==?null)?{??
????????????????????????continue;??
????????????????????}??
retFlag?=?true;??
????????????????}??
????????????????conn.unwatch();??
????????????????break;??
????????????}??
????????}?catch?(JedisException?e)?{??
????????????e.printStackTrace();??
????????}?finally?{??
????????????if?(conn?!=?null)?{??
????????????????conn.close();??
????????????}??
????????}??
????????return?retFlag;??
????}??
}?
5、測(cè)試
例子中使用50個(gè)線程模擬秒殺一個(gè)商品，使用–運(yùn)算符來實(shí)現(xiàn)商品減少，從結(jié)果有序性就可以看出是否為加鎖狀態(tài)。
模擬秒殺服務(wù)，在其中配置了jedis線程池，在初始化的時(shí)候傳給分布式鎖，供其使用。
/**??
?*?Created?by?素小暖?on?2020/2/12.??
?*/??
public?class?Service?{??
private?static?JedisPoolpool?=?null;??
private?DistributedLocklock?=?new?DistributedLock(pool);??
intn?=?500;??
????static?{??
JedisPoolConfigconfig?=?new?JedisPoolConfig();??
????????//?設(shè)置最大連接數(shù)??
????????config.setMaxTotal(200);??
????????//?設(shè)置最大空閑數(shù)??
????????config.setMaxIdle(8);??
????????//?設(shè)置最大等待時(shí)間??
????????config.setMaxWaitMillis(1000?*?100);??
????????//?在borrow一個(gè)jedis實(shí)例時(shí)，是否需要驗(yàn)證，若為true，則所有jedis實(shí)例均是可用的??
????????config.setTestOnBorrow(true);??
pool?=?new?JedisPool(config,?"127.0.0.1",?6379,?3000);??
????}??
????public?void?seckill()?{??
????????//?返回鎖的value值，供釋放鎖時(shí)候進(jìn)行判斷??
Stringidentifier?=?lock.lockWithTimeout("resource",?5000,?1000);??
????????System.out.println(Thread.currentThread().getName()?+?"獲得了鎖");??
????????System.out.println(--n);??
????????lock.releaseLock("resource",?identifier);??
????}??
}?
結(jié)果如下，有序的：
若注釋使用鎖的部分：
public?void?seckill()?{??
????//?返回鎖的value值，供釋放鎖時(shí)候進(jìn)行判斷??
//Stringindentifier?=?lock.lockWithTimeout("resource",?5000,?1000);??
????System.out.println(Thread.currentThread().getName()?+?"獲得了鎖");??
????System.out.println(--n);??
????//lock.releaseLock("resource",?indentifier);??
}?
從結(jié)果可以看出，有一些是異步進(jìn)行的：
六、基于Zookeeper實(shí)現(xiàn)分布式
Zookeeper是一個(gè)為分布式應(yīng)用提供一致性服務(wù)的開源組件，它內(nèi)部是一個(gè)分層的文件系統(tǒng)目錄樹結(jié)構(gòu)，規(guī)定同一目錄下只能有一個(gè)唯一文件名。
基于Zookeeper實(shí)現(xiàn)分布式鎖的步驟如下：
1、創(chuàng)建一個(gè)目錄mylock；
2、創(chuàng)建A想獲取鎖就在mylock目錄下創(chuàng)建臨時(shí)順序節(jié)點(diǎn)；
3、獲取mylock目錄下所有的子節(jié)點(diǎn)，然后獲取比自己小的兄弟節(jié)點(diǎn)，如果不存在，則說明當(dāng)前線程順序號(hào)最小，獲取鎖；
4、線程B獲取所有節(jié)點(diǎn)，判斷自己不是最小節(jié)點(diǎn)，設(shè)置監(jiān)聽比自己次小的節(jié)點(diǎn)；
5、線程A處理完，刪除自己的節(jié)點(diǎn)，線程B監(jiān)聽到變更事件，判斷自己是不是最小節(jié)點(diǎn)，如果是，獲取鎖。
這里推薦一個(gè)Apache的開源庫Curator，它是一個(gè)ZooKeeper客戶端，Curator提供的InterProcessMutex是分布式鎖的實(shí)現(xiàn)，acquire方法用于獲取鎖，release方法用于釋放鎖。
優(yōu)點(diǎn)：具備高可用、可重入、阻塞鎖特性，可解決失效死鎖的問題。
缺點(diǎn)：因?yàn)樾枰l繁的創(chuàng)建和刪除節(jié)點(diǎn)，性能上不如Redis方式。
七、總結(jié)
上面的三種實(shí)現(xiàn)方式，沒有在所有場(chǎng)合都是完美的，所以，應(yīng)根據(jù)不同的應(yīng)用場(chǎng)景選擇最適合的實(shí)現(xiàn)方式。
在分布式環(huán)境中，對(duì)資源進(jìn)行上鎖有時(shí)候是很重要的，比如秒殺，這時(shí)候使用分布式鎖可以很好地控制資源。
當(dāng)然，在具體使用中，還要考慮很多因素，比如超時(shí)時(shí)間的選取，獲取鎖時(shí)間的選取對(duì)并發(fā)量都有很大的影響，上述實(shí)現(xiàn)的分布式鎖只是一個(gè)簡(jiǎn)單的實(shí)現(xiàn)，主要是一種思想，僅做入門參考。
以上內(nèi)容都是我自己的一些感想，分享出來歡迎大家指正，順便求一波關(guān)注
作者：素小暖OSC來源：開源中國
