簡介

分布式鎖在分布式系統(tǒng)中非常常見亮蒋，比如對公共資源進(jìn)行操作妆毕，如賣車票，同一時(shí)刻只能有一個(gè)節(jié)點(diǎn)將某個(gè)特定座位的票賣出去趁怔；如避免緩存失效帶來的大量請求訪問數(shù)據(jù)庫的問題

設(shè)計(jì)

這非常像一道面試題：如何實(shí)現(xiàn)一個(gè)分布式鎖薪前？在簡介中，基本上已經(jīng)對這個(gè)分布式工具提出了一些需求铺浇，你可以不著急看下面的答案垛膝，自己思考一下分布式鎖應(yīng)該如何實(shí)現(xiàn)丁稀？

首先我們需要一個(gè)簡單的答題套路：需求分析线衫、系統(tǒng)設(shè)計(jì)惑折、實(shí)現(xiàn)方式、缺點(diǎn)不足

需求分析

能夠在高并發(fā)的分布式的系統(tǒng)中應(yīng)用

需要實(shí)現(xiàn)鎖的基本特性：一旦某個(gè)鎖被分配出去白热，那么其他的節(jié)點(diǎn)無法再進(jìn)入這個(gè)鎖所管轄范圍內(nèi)的資源敞咧；失效機(jī)制避免無限時(shí)長的鎖與死鎖

進(jìn)一步實(shí)現(xiàn)鎖的高級特性和JUC并發(fā)工具類似功能更好：可重入、阻塞與非阻塞乍恐、公平與非公平测砂、JUC的并發(fā)工具（Semaphore, CountDownLatch, CyclicBarrier）

系統(tǒng)設(shè)計(jì)

轉(zhuǎn)換成設(shè)計(jì)是如下幾個(gè)要求：

對加鎖、解鎖的過程需要是高性能呜投、原子性的

需要在某個(gè)分布式節(jié)點(diǎn)都能訪問到的公共平臺上進(jìn)行鎖狀態(tài)的操作

所以存璃，我們分析出系統(tǒng)的構(gòu)成應(yīng)該要有鎖狀態(tài)存儲模塊、連接存儲模塊的連接池模塊粘招、鎖內(nèi)部邏輯模塊

鎖狀態(tài)存儲模塊

分布式鎖的存儲有三種常見實(shí)現(xiàn)偎球，因?yàn)槟軡M足實(shí)現(xiàn)鎖的這些條件：高性能加鎖解鎖、操作的原子性袍冷、是分布式系統(tǒng)中不同節(jié)點(diǎn)都可以訪問的公共平臺：

數(shù)據(jù)庫（利用主鍵唯一規(guī)則猫牡、MySQL行鎖）

基于Redis的NX、EX參數(shù)

Zookeeper臨時(shí)有序節(jié)點(diǎn)

由于鎖常常是在高并發(fā)的情況下才會使用到的分布式控制工具乃戈，所以使用數(shù)據(jù)庫實(shí)現(xiàn)會對數(shù)據(jù)庫造成一定的壓力，連接池爆滿問題缩歪，所以不推薦數(shù)據(jù)庫實(shí)現(xiàn)谍憔；我們還需要維護(hù)Zookeeper集群，實(shí)現(xiàn)起來還是比較復(fù)雜的逛球。如果不是原有系統(tǒng)就依賴Zookeeper苫昌，同時(shí)壓力不大的情況下。一般不使用Zookeeper實(shí)現(xiàn)分布式鎖奥务。所以緩存實(shí)現(xiàn)分布式鎖還是比較常見的袜硫，因?yàn)?b>緩存比較輕量、緩存的響應(yīng)快帚称、吞吐高秽澳、還有自動失效的機(jī)制保證鎖一定能釋放。

連接池模塊

可使用JedisPool實(shí)現(xiàn)瞻坝，如果后期性能不佳杏瞻，可考慮參照HikariCP自己實(shí)現(xiàn)

鎖內(nèi)部邏輯模塊

基本功能：加鎖捞挥、解鎖忧吟、超時(shí)釋放

高級功能：可重入、阻塞與非阻塞讹俊、公平與非公平、JUC并發(fā)工具功能

實(shí)現(xiàn)方式

存儲模塊使用Redis仍劈，連接池模塊暫時(shí)使用JedisPool贩疙，鎖的內(nèi)部邏輯將從基本功能開始，逐步實(shí)現(xiàn)高級功能这溅，下面就是各種功能實(shí)現(xiàn)的具體思路與代碼了。

加鎖悲靴、超時(shí)釋放

NX是Redis提供的一個(gè)原子操作癞尚，如果指定key存在，那么NX失敗否纬，如果不存在會進(jìn)行set操作并返回成功临燃。我們可以利用這個(gè)來實(shí)現(xiàn)一個(gè)分布式的鎖，主要思路就是膜廊，set成功表示獲取鎖爪瓜，set失敗表示獲取失敗，失敗后需要重試蝶缀。再加上EX參數(shù)可以讓該key在超時(shí)之后自動刪除薄货。

下面是一個(gè)阻塞鎖的加鎖操作，將循環(huán)去掉并返回執(zhí)行結(jié)果就能寫出非阻塞鎖（就不粘出來了）：

public void lock(String key, String request, int timeout) throws InterruptedException {

? ? Jedis jedis = jedisPool.getResource();

? ? while (timeout >= 0) {

? ? ? ? String result = jedis.set(LOCK_PREFIX + key, request, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, DEFAULT_EXPIRE_TIME);

? ? ? ? if (LOCK_MSG.equals(result)) {

? ? ? ? ? ? jedis.close();

? ? ? ? ? ? return;

? ? ? ? }

? ? ? ? Thread.sleep(DEFAULT_SLEEP_TIME);

? ? ? ? timeout -= DEFAULT_SLEEP_TIME;

? ? }

}

但超時(shí)時(shí)間這個(gè)參數(shù)會引發(fā)一個(gè)問題柄慰，如果超過超時(shí)時(shí)間但是業(yè)務(wù)還沒執(zhí)行完會導(dǎo)致并發(fā)問題，其他進(jìn)程就會執(zhí)行業(yè)務(wù)代碼藏研，至于如何改進(jìn)蠢挡，下文會講到占锯。

解鎖

最常見的解鎖代碼就是直接使用jedis.del()方法刪除鎖消略，這種不先判斷鎖的擁有者而直接解鎖的方式，會導(dǎo)致任何客戶端都可以隨時(shí)進(jìn)行解鎖却紧，即使這把鎖不是它的胎撤。

比如可能存在這樣的情況：客戶端A加鎖，一段時(shí)間之后客戶端A解鎖巫俺，在執(zhí)行jedis.del()之前肿男，鎖突然過期了，此時(shí)客戶端B嘗試加鎖成功嘹承，然后客戶端A再執(zhí)行del()方法如庭，則將客戶端B的鎖給解除了。

所以我們需要一個(gè)具有原子性的方法來解鎖骤竹，并且要同時(shí)判斷這把鎖是不是自己的往毡。由于Lua腳本在Redis中執(zhí)行是原子性的卖擅，所以可以寫成下面這樣：

public boolean unlock(String key, String value) {

? ? Jedis jedis = jedisPool.getResource();

? ? String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";

? ? Object result = jedis.eval(script, Collections.singletonList(LOCK_PREFIX + key), Collections.singletonList(value));

? ? jedis.close();

? ? return UNLOCK_MSG.equals(result);

}

來用測試梭一把

此時(shí)我們可以來寫個(gè)測試來試試有沒有達(dá)到我們想要的效果，上面的代碼都寫在src/main/java下的RedisLock里挎狸，下面的測試代碼需要寫在src/test/java里断楷，因?yàn)閱卧獪y試只是測試代碼的邏輯，無法測試真實(shí)連接Redis之后的表現(xiàn)恐锣，也沒辦法體驗(yàn)到被鎖住帶來的緊張又刺激的快感舞痰，所以本項(xiàng)目中主要以集成測試為主，如果你想試試帶Mock的單元測試玷禽，可以看看這篇文章呀打。

那么集成測試會需要依賴一個(gè)Redis實(shí)例贬丛，為了避免你在本地去裝個(gè)Redis來跑測試，我用到了一個(gè)嵌入式的Redis工具以及如下代碼來幫我們New一個(gè)Redis實(shí)例额获，盡情去連接吧 ~ 代碼可參看EmbeddedRedis類焕阿。另外，集成測試使用到了Spring撤摸，是不是倍感親切褒纲？相當(dāng)于也提供了一個(gè)集成Spring的例子。

@Configuration

public class EmbeddedRedis implements ApplicationRunner {

? ? private static RedisServer redisServer;

? ? @PreDestroy

? ? public void stopRedis() {

? ? ? ? redisServer.stop();

? ? }

? ? @Override

? ? public void run(ApplicationArguments applicationArguments) {

? ? ? ? redisServer = RedisServer.builder().setting("bind 127.0.0.1").setting("requirepass test").build();

? ? ? ? redisServer.start();

? ? }

}

對于需要考慮并發(fā)的代碼下的測試是比較難且比較難以達(dá)到檢測代碼質(zhì)量的目的的衫嵌，因?yàn)闇y試用例會用到多線程的環(huán)境楔绞，不一定能百分百通過且難以重現(xiàn)，但本項(xiàng)目的分布式鎖是一個(gè)比較簡單的并發(fā)場景桦锄，所以我會盡可能保證測試是有意義的蔫耽。

我第一個(gè)測試用例是想測試一下鎖的互斥能力，能否在A拿到鎖之后图甜，B就無法立即拿到鎖：

@Test

public void shouldWaitWhenOneUsingLockAndTheOtherOneWantToUse() throws InterruptedException {

? ? Thread t = new Thread(() -> {

? ? ? ? try {

? ? ? ? ? ? redisLock.lock(lock1Key, UUID.randomUUID().toString());

? ? ? ? } catch (InterruptedException e) {

? ? ? ? ? ? e.printStackTrace();

? ? ? ? }

? ? });

? ? t.start();

? ? t.join();

? ? long startTime = System.currentTimeMillis();

? ? redisLock.lock(lock1Key, UUID.randomUUID().toString(), 3000);

? ? assertThat(System.currentTimeMillis() - startTime).isBetween(2500L, 3500L);

}

但這僅僅測試了加鎖操作時(shí)候的互斥性鳖眼，但是沒有測試解鎖是否會成功以及解鎖之后原來等待鎖的進(jìn)程會繼續(xù)進(jìn)行具帮，所以你可以參看一下testLockAndUnlock方法是如何測試的。不要覺得寫測試很簡單匪凡，想清楚測試的各種情況掘猿，設(shè)計(jì)測試情景并實(shí)現(xiàn)并不容易。然而以后寫的測試不會單獨(dú)拿出來講衬衬，畢竟本文想關(guān)注的還是分布式鎖的實(shí)現(xiàn)嘛改橘。

超時(shí)釋放導(dǎo)致的并發(fā)問題

問題：如果A拿到鎖之后設(shè)置了超時(shí)時(shí)長，但是業(yè)務(wù)執(zhí)行的時(shí)長超過了超時(shí)時(shí)長狮惜，導(dǎo)致A還在執(zhí)行業(yè)務(wù)但是鎖已經(jīng)被釋放碾篡，此時(shí)其他進(jìn)程就會拿到鎖從而執(zhí)行相同的業(yè)務(wù)筏餐，此時(shí)因?yàn)椴l(fā)導(dǎo)致分布式鎖失去了意義。

如果你說我可以通過在key快要過期的時(shí)候判斷下任務(wù)有沒有執(zhí)行完畢穆律，如果還沒有那就自動延長過期時(shí)間，那么確實(shí)可以解決并發(fā)的問題罢杉，但是超時(shí)時(shí)長也就失去了意義贡歧，我設(shè)置超時(shí)時(shí)長就是為了想在超時(shí)的時(shí)候自動釋放鎖赋秀，避免其他進(jìn)程被阻塞猎莲。所以個(gè)人認(rèn)為最好的解決方式是在鎖超時(shí)的時(shí)候通知服務(wù)器去停掉超時(shí)任務(wù)，但是結(jié)合上Redis的消息通知機(jī)制不免有些過重了樟遣；或者讓業(yè)務(wù)代碼自己去檢查是否執(zhí)行超時(shí)身笤，但是工具不就是讓業(yè)務(wù)實(shí)現(xiàn)人員更加關(guān)注業(yè)務(wù)嗎？

所以這個(gè)問題上瞻佛，分布式鎖的Redis實(shí)現(xiàn)并不靠譜

單點(diǎn)故障導(dǎo)致的并發(fā)問題

建立主從復(fù)制架構(gòu)伤柄，但是還是會由于主節(jié)點(diǎn)掛掉導(dǎo)致某些數(shù)據(jù)還沒同步就已經(jīng)丟失文搂，所以推薦多主架構(gòu)，有N個(gè)獨(dú)立的master服務(wù)器煤蹭，客戶端會向所有的服務(wù)器發(fā)送獲取鎖的操作疯兼。

可以繼續(xù)優(yōu)化的地方

提供多主配置方式與加鎖解鎖實(shí)現(xiàn)

使用訂閱解鎖消息與Semaphore代替Thread.sleep()避免時(shí)間浪費(fèi)，可參考Redisson中RedissonLock的lockInterruptibly方法

Java高架構(gòu)師待侵、分布式架構(gòu)姨裸、高可擴(kuò)展、高性能那先、高并發(fā)、性能優(yōu)化斤葱、Spring boot揖闸、Redis汤纸、ActiveMQ衩茸、Nginx、Mycat贮泞、Netty楞慈、Jvm大型分布式項(xiàng)目實(shí)戰(zhàn)學(xué)習(xí)架構(gòu)師視頻免費(fèi)學(xué)習(xí)加群：835638062 點(diǎn)擊鏈接加入群聊【Java高級架構(gòu)】：https://jq.qq.com/?_wv=1027&k=5S3kL3v