我們在開發(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ù)載均衡，

如果我們業(yè)務(wù)中確實(shí)存在這個(gè)場景的話，我們就需要一種方法解決這個(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)用都是分布式部署的，分布式場景中的數(shù)據(jù)一致性問題一直是一個(gè)比較重要的話題。分布式的CAP理論告訴我們“任何一個(gè)分布式系統(tǒng)都無法同時(shí)滿足一致性、可用性和分區(qū)容錯(cuò)性，最多只能滿足兩項(xiàng)?！彼?，很多系統(tǒng)在設(shè)計(jì)之初就要對(duì)這三者進(jìn)行取舍。在互聯(lián)網(wǎng)領(lǐng)域的絕大多數(shù)的場景中，都需要犧牲掉一致性來換取系統(tǒng)的高可用性，系統(tǒng)往往只需要保證最終一致性，只要這個(gè)最終時(shí)間是在用戶可以接受的范圍內(nèi)即可。

在很多場景中，為了保證數(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è)表

2、想要執(zhí)行某個(gè)方法，就要使用這個(gè)方法名向表中插入數(shù)據(jù)

INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '測試的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、使用命令簡介

（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、分布式鎖的簡單代碼

/**

* 分布式鎖的簡單實(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) {

? ? ? ? Jedis conn = null;

? ? ? ? String retIdentifier = null;

? ? ? ? try {

? ? ? ? ? ? // 獲取連接

? ? ? ? ? ? conn = jedisPool.getResource();

? ? ? ? ? ? // 隨機(jī)生成一個(gè)value

? ? ? ? ? ? String identifier = UUID.randomUUID().toString();

? ? ? ? ? ? // 鎖名，即key值

? ? ? ? ? ? String lockKey = "lock:" + lockName;

? ? ? ? ? ? // 超時(shí)時(shí)間，上鎖后超過此時(shí)間則自動(dòng)釋放鎖

? ? ? ? ? ? int lockExpire = (int) (timeout / 1000);

? ? ? ? ? ? // 獲取鎖的超時(shí)時(shí)間，超過這個(gè)時(shí)間則放棄獲取鎖

? ? ? ? ? ? long end = 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) {

? ? ? ? Jedis conn = null;

? ? ? ? String lockKey = "lock:" + lockName;

? ? ? ? boolean retFlag = false;

? ? ? ? try {

? ? ? ? ? ? conn = jedisPool.getResource();

? ? ? ? ? ? while (true) {

? ? ? ? ? ? ? ? // 監(jiān)視lock，準(zhǔn)備開始事務(wù)

? ? ? ? ? ? ? ? conn.watch(lockKey);

? ? ? ? ? ? ? ? // 通過前面返回的value值判斷是不是該鎖，若是該鎖，則刪除，釋放鎖

? ? ? ? ? ? ? ? if (identifier.equals(conn.get(lockKey))) {

? ? ? ? ? ? ? ? ? ? Transaction transaction = 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、測試

例子中使用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 JedisPool pool = null;

? ? private DistributedLock lock = new DistributedLock(pool);

? ? int n = 500;

? ? static {

? ? ? ? JedisPoolConfig config = 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)行判斷

? ? ? ? String identifier = lock.lockWithTimeout("resource", 5000, 1000);

? ? ? ? System.out.println(Thread.currentThread().getName() + "獲得了鎖");

? ? ? ? System.out.println(--n);

? ? ? ? lock.releaseLock("resource", identifier);

? ? }

}

結(jié)果如下，有序的：

<img src="https://pic1.zhimg.com/v2-1f9616506e233f5c12a81ce6a377a754_b.jpeg" data-caption="" data-size="normal" data-rawwidth="191" data-rawheight="392" class="content_image" width="191"/>

若注釋使用鎖的部分：

public void seckill() {

? ? // 返回鎖的value值，供釋放鎖時(shí)候進(jìn)行判斷

? ? //String indentifier = lock.lockWithTimeout("resource", 5000, 1000);

? ? System.out.println(Thread.currentThread().getName() + "獲得了鎖");

? ? System.out.println(--n);

? ? //lock.releaseLock("resource", indentifier);

}

從結(jié)果可以看出，有一些是異步進(jìn)行的：

<img src="https://pic1.zhimg.com/v2-7239978a2daf7d8bf5804ad898fb75bc_b.jpg" data-caption="" data-size="normal" data-rawwidth="204" data-rawheight="446" class="content_image" width="204"/>

六、基于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方式。

<img src="https://pic4.zhimg.com/v2-91d7cbeaba5c3aa5c6921db4b393fe47_b.jpg" data-caption="" data-size="normal" data-rawwidth="600" data-rawheight="400" class="origin_image zh-lightbox-thumb" width="600" data-original="https://pic4.zhimg.com/v2-91d7cbeaba5c3aa5c6921db4b393fe47_r.jpg"/>

七、總結(jié)

上面的三種實(shí)現(xiàn)方式，沒有在所有場合都是完美的，所以，應(yīng)根據(jù)不同的應(yīng)用場景選擇最適合的實(shí)現(xiàn)方式。

在分布式環(huán)境中，對(duì)資源進(jìn)行上鎖有時(shí)候是很重要的，比如秒殺，這時(shí)候使用分布式鎖可以很好地控制資源。

當(dāng)然，在具體使用中，還要考慮很多因素，比如超時(shí)時(shí)間的選取，獲取鎖時(shí)間的選取對(duì)并發(fā)量都有很大的影響，上述實(shí)現(xiàn)的分布式鎖只是一個(gè)簡單的實(shí)現(xiàn)，主要是一種思想，僅做入門參考