## 寫在前面 > 最近，很多小夥伴留言說，在學習高併發程式設計時，不太明白分散式鎖是用來解決什麼問題的，還有不少小夥伴甚至連分散式鎖是什麼都不太明白。明明在生產環境上使用了自己開發的分散式鎖，為什麼還會出現問題呢？同樣的程式，加上分散式鎖後，效能差了幾個數量級！這又是為什麼呢？今天，我們就來說說如何在高併發環境下實現分散式鎖，不是所有的鎖都是高併發的。 > > 萬字長文，帶你深入解密高併發環境下的分散式鎖架構，不是所有的鎖都是分散式鎖！！！ 究竟什麼樣的鎖才能更好的支援高併發場景呢？今天，我們就一起解密高併發環境下典型的分散式鎖架構，結合【高併發】專題下的其他文章，學以致用。 ## 鎖用來解決什麼問題呢？ 在我們編寫的應用程式或者高併發程式中，不知道大家有沒有想過一個問題，就是我們為什麼需要引入鎖？鎖為我們解決了什麼問題呢？ 在很多業務場景下，我們編寫的應用程式中會存在很多的 **資源競爭** 的問題。而我們在高併發程式中，引入鎖，就是為了解決這些資源競爭的問題。 ## 電商超賣問題 這裡，我們可以列舉一個簡單的業務場景。比如，在電子商務（商城）的業務場景中，提交訂單購買商品時，首先需要查詢相應商品的庫存是否足夠，只有在商品庫存數量足夠的前提下，才能讓使用者成功的下單。下單時，我們需要在庫存數量中減去使用者下單的商品數量，並將庫存操作的結果資料更新到資料庫中。整個流程我們可以簡化成下圖所示。  很多小夥伴也留言說，讓我給出程式碼，這樣能夠更好的學習和掌握相關的知識。好吧，這裡，我也給出相應的程式碼片段吧。我們可以使用下面的程式碼片段來表示使用者的下單操作，我這裡將商品的庫存資訊儲存在了Redis中。 ```java @RequestMapping("/submitOrder") public String submitOrder(){ int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock")); if(stock > 0){ stock -= 1; stringRedisTemplate.opsForValue().set("stock", String.valueOf(stock)); logger.debug("庫存扣減成功，當前庫存為：{}", stock); }else{ logger.debug("庫存不足，扣減庫存失敗"); throw new OrderException("庫存不足，扣減庫存失敗"); } return "success"; } ``` **注意：上述程式碼片段比較簡單，只是為了方便大家理解，真正專案中的程式碼就不能這麼寫了。** 上述的程式碼看似是沒啥問題的，但是我們不能只從程式碼表面上來觀察程式碼的執行順序。這是因為在JVM中程式碼的執行順序未必是按照我們書寫程式碼的順序執行的。即使在JVM中程式碼是按照我們書寫的順序執行，那我們對外提供的介面一旦暴露出去，就會有成千上萬的客戶端來訪問我們的介面。所以說，我們暴露出去的介面是會被併發訪問的。 **試問，上面的程式碼在高併發環境下是執行緒安全的嗎？答案肯定不是執行緒安全的，因為上述扣減庫存的操作會出現並行執行的情況。** 我們可以使用Apache JMeter來對上述介面進行測試，這裡，我使用Apache JMeter對上述介面進行測試。  在Jmeter中，我將執行緒的併發度設定為3，接下來的配置如下所示。  以HTTP GET請求的方式來併發訪問提交訂單的介面。此時，執行JMeter來訪問介面，命令列會打印出下面的日誌資訊。 ```bash 庫存扣減成功，當前庫存為：49 庫存扣減成功，當前庫存為：49 庫存扣減成功，當前庫存為：49 ``` 這裡，我們明明請求了3次，也就是說，提交了3筆訂單，為什麼扣減後的庫存都是一樣的呢？這種現象在電商領域有一個專業的名詞叫做 **“超賣”** 。 如果一個大型的高併發電商系統，比如淘寶、天貓、京東等，出現了超賣現象，那損失就無法估量了！架構設計和開發電商系統的人員估計就要通通下崗了。所以，**作為技術人員，我們一定要嚴謹的對待技術，嚴格做好系統的每一個技術環節。** ## JVM中提供的鎖 JVM中提供的synchronized和Lock鎖，相信大家並不陌生了，很多小夥伴都會使用這些鎖，也能使用這些鎖來實現一些簡單的執行緒互斥功能。那麼，作為立志要成為架構師的你，是否瞭解過JVM鎖的底層原理呢？ ### JVM鎖原理 說到JVM鎖的原理，我們就不得不限說說Java中的物件頭了。 **Java中的物件頭** > 每個Java物件都有物件頭。如果是⾮陣列型別，則⽤2個字寬來儲存物件頭，如果是陣列，則會⽤3個字寬來儲存物件頭。在32位處理器中，⼀個字寬是32位；在64位虛擬機器中，⼀個字寬是64位。 物件頭的內容如下表 。 | 長度 | 內容 | 說明 | | -------- | --------------------- | ---------------------------- | | 32/64bit | Mark Word | 儲存物件的hashCode或鎖資訊等 | | 32/64bit | Class Metadata Access | 儲存到物件型別資料的指標 | | 32/64bit | Array length | 陣列的長度（如果是陣列） | Mark Work的格式如下所示。 | 鎖狀態 | 29bit或61bit | 1bit是否是偏向鎖？ | 2bit鎖標誌位 | | -------- | ---------------------------- | -------------------------- | ------------ | | 無鎖 | | 0 | 01 | | 偏向鎖 | 執行緒ID | 1 | 01 | | 輕量級鎖 | 指向棧中鎖記錄的指標 | 此時這一位不用於標識偏向鎖 | 00 | | 重量級鎖 | 指向互斥量（重量級鎖）的指標 | 此時這一位不用於標識偏向鎖 | 10 | | GC標記 | | 此時這一位不用於標識偏向鎖 | 11 | 可以看到，當物件狀態為偏向鎖時， Mark Word 儲存的是偏向的執行緒ID；當狀態為輕量級鎖時， Mark Word 儲存的是指向執行緒棧中 Lock Record 的指標；當狀態為重量級鎖時， Mark Word 為指向堆中的monitor物件的指標 。 > 有關Java物件頭的知識，參考《深入淺出Java多執行緒》。 **JVM鎖原理** 簡單點來說，JVM中鎖的原理如下。 在Java物件的物件頭上，有一個鎖的標記，比如，第一個執行緒執行程式時，檢查Java物件頭中的鎖標記，發現Java物件頭中的鎖標記為未加鎖狀態，於是為Java物件進行了加鎖操作，將物件頭中的鎖標記設定為鎖定狀態。第二個執行緒執行同樣的程式時，也會檢查Java物件頭中的鎖標記，此時會發現Java物件頭中的鎖標記的狀態為鎖定狀態。於是，第二個執行緒會進入相應的阻塞佇列中進行等待。 **這裡有一個關鍵點就是Java物件頭中的鎖標記如何實現。** ### JVM鎖的短板 JVM中提供的synchronized和Lock鎖都是JVM級別的，大家都知道，當執行一個Java程式時，會啟動一個JVM程序來執行我們的應用程式。synchronized和Lock在JVM級別有效，也就是說，synchronized和Lock在同一Java程序內有效。如果我們開發的應用程式是分散式的，那麼只是使用synchronized和Lock來解決分散式場景下的高併發問題，就會顯得有點力不從心了。 **synchronized和Lock支援JVM同一程序內部的執行緒互斥** synchronized和Lock在JVM級別能夠保證高併發程式的互斥，我們可以使用下圖來表示。  但是，當我們將應用程式部署成分散式架構，或者將應用程式在不同的JVM程序中執行時，synchronized和Lock就不能保證分散式架構和多JVM程序下應用程式的互斥性了。 **synchronized和Lock不能實現多JVM程序之間的執行緒互斥** 分散式架構和多JVM程序的本質都是將應用程式部署在不同的JVM例項中，也就是說，其本質還是多JVM程序。  ## 分散式鎖 我們在實現分散式鎖時，可以參照JVM鎖實現的思想，JVM鎖在為物件加鎖時，通過改變Java物件的物件頭中的鎖的標誌位來實現，也就是說，所有的執行緒都會訪問這個Java物件的物件頭中的鎖標誌位。  我們同樣以這種思想來實現分散式鎖，當我們將應用程式進行拆分並部署成分散式架構時，所有應用程式中的執行緒訪問共享變數時，都到同一個地方去檢查當前程式的臨界區是否進行了加鎖操作，而是否進行了加鎖操作，我們在統一的地方使用相應的狀態來進行標記。  可以看到，在分散式鎖的實現思想上，與JVM鎖相差不大。而在實現分散式鎖中，**儲存加鎖狀態的服務可以使用MySQL、Redis和Zookeeper實現。** 但是，在網際網路高併發環境中， **使用Redis實現分散式鎖的方案是使用的最多的。** 接下來，我們就使用Redis來深入解密分散式鎖的架構設計。 ## Redis如何實現分散式鎖 ### Redis命令 在Redis中，有一個不常使用的命令如下所示。 ```bash SETNX key value ``` 這條命令的含義就是“SET if Not Exists”，即不存在的時候才會設定值。 只有在key不存在的情況下，將鍵key的值設定為value。如果key已經存在，則SETNX命令不做任何操作。 這個命令的返回值如下。 * 命令在設定成功時返回1。 * 命令在設定失敗時返回0。 所以，我們在分散式高併發環境下，可以使用Redis的SETNX命令來實現分散式鎖。假設此時有執行緒A和執行緒B同時訪問臨界區程式碼，假設執行緒A首先執行了SETNX命令，並返回結果1，繼續向下執行。而此時執行緒B再次執行SETNX命令時，返回的結果為0，則執行緒B不能繼續向下執行。只有當執行緒A執行DELETE命令將設定的鎖狀態刪除時，執行緒B才會成功執行SETNX命令設定加鎖狀態後繼續向下執行。 ### 引入分散式鎖 瞭解瞭如何使用Redis中的命令實現分散式鎖後，我們就可以對下單介面進行改造了，加入分散式鎖，如下所示。 ```java /** * 為了演示方便，我這裡就簡單定義了一個常量作為商品的id * 實際工作中，這個商品id是前端進行下單操作傳遞過來的引數 */ public static final String PRODUCT_ID = "100001"; @RequestMapping("/submitOrder") public String submitOrder(){ //通過stringRedisTemplate來呼叫Redis的SETNX命令，key為商品的id，value為字串“binghe” //實際上，value可以為任意的字元換 Boolean isLocked = stringRedisTemplate.opsForValue().setIfAbsent(PRODUCT_ID, "binghe"); //沒有拿到鎖，返回下單失敗 if(!isLock){ return "failure"; } int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock")); if(stock > 0){ stock -= 1; stringRedisTemplate.opsForValue().set("stock", String.valueOf(stock)); logger.debug("庫存扣減成功，當前庫存為：{}", stock); }else{ logger.debug("庫存不足，扣減庫存失敗"); throw new OrderException("庫存不足，扣減庫存失敗"); } //業務執行完成，刪除PRODUCT_ID key stringRedisTemplate.delete(PRODUCT_ID); return "success"; } ``` 那麼，在上述程式碼中，我們加入了分散式鎖的操作，那上述程式碼是否能夠在高併發場景下保證業務的原子性呢？答案是可以保證業務的原子性。但是，**在實際場景中，上面實現分散式鎖的程式碼是不可用的！！** 假設當執行緒A首先執行stringRedisTemplate.opsForValue()的setIfAbsent()方法返回true，繼續向下執行，正在執行業務程式碼時，丟擲了異常，執行緒A直接退出了JVM。此時，stringRedisTemplate.delete(PRODUCT_ID);程式碼還沒來得及執行，之後所有的執行緒進入提交訂單的方法時，呼叫stringRedisTemplate.opsForValue()的setIfAbsent()方法都會返回false。導致後續的所有下單操作都會失敗。**這就是分散式場景下的死鎖問題。** **所以，上述程式碼中實現分散式鎖的方式在實際場景下是不可取的！！** ### 引入try-finally程式碼塊 說到這，相信小夥伴們都能夠想到，使用try-finall程式碼塊啊，接下來，我們為下單介面的方法加上try-finally程式碼塊。 ```java /** * 為了演示方便，我這裡就簡單定義了一個常量作為商品的id * 實際工作中，這個商品id是前端進行下單操作傳遞過來的引數 */ public static final String PRODUCT_ID = "100001"; @RequestMapping("/submitOrder") public String submitOrder(){ //通過stringRedisTemplate來呼叫Redis的SETNX命令，key為商品的id，value為字串“binghe” //實際上，value可以為任意的字元換 Boolean isLocked = stringRedisTemplate.opsForValue().setIfAbsent(PRODUCT_ID, "binghe"); //沒有拿到鎖，返回下單失敗 if(!isLock){ return "failure"; } try{ int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock")); if(stock > 0){ stock -= 1; stringRedisTemplate.opsForValue().set("stock", String.valueOf(stock)); logger.debug("庫存扣減成功，當前庫存為：{}", stock); }else{ logger.debug("庫存不足，扣減庫存失敗"); throw new OrderException("庫存不足，扣減庫存失敗"); } }finally{ //業務執行完成，刪除PRODUCT_ID key stringRedisTemplate.delete(PRODUCT_ID); } return "success"; } ``` 那麼，上述程式碼是否真正解決了死鎖的問題呢？我們在寫程式碼時，不能只盯著程式碼本身，覺得上述程式碼沒啥問題了。實際上，生產環境是非常複雜的。如果執行緒在成功加鎖之後，執行業務程式碼時，還沒來得及執行刪除鎖標誌的程式碼，此時，伺服器宕機了，程式並沒有優雅的退出JVM。也會使得後續的執行緒進入提交訂單的方法時，因無法成功的設定鎖標誌位而下單失敗。所以說，上述的程式碼仍然存在問題。 ### 引入Redis超時機制 在Redis中可以設定快取的自動過期時間，我們可以將其引入到分散式鎖的實現中，如下程式碼所示。 ```java /** * 為了演示方便，我這裡就簡單定義了一個常量作為商品的id * 實際工作中，這個商品id是前端進行下單操作傳遞過來的引數 */ public static final String PRODUCT_ID = "100001"; @RequestMapping("/submitOrder") public String submitOrder(){ //通過stringRedisTemplate來呼叫Redis的SETNX命令，key為商品的id，value為字串“binghe” //實際上，value可以為任意的字元換 Boolean isLocked = stringRedisTemplate.opsForValue().setIfAbsent(PRODUCT_ID, "binghe"); //沒有拿到鎖，返回下單失敗 if(!isLock){ return "failure"; } try{ stringRedisTemplate.expire(PRODUCT_ID, 30, TimeUnit.SECONDS); int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock")); if(stock > 0){ stock -= 1; stringRedisTemplate.opsForValue().set("stock", String.valueOf(stock)); logger.debug("庫存扣減成功，當前庫存為：{}", stock); }else{ logger.debug("庫存不足，扣減庫存失敗"); throw new OrderException("庫存不足，扣減庫存失敗"); } }finally{ //業務執行完成，刪除PRODUCT_ID key stringRedisTemplate.delete(PRODUCT_ID); } return "success"; } ``` 在上述程式碼中，我們加入瞭如下一行程式碼來為Redis中的鎖標誌設定過期時間。 ```java stringRedisTemplate.expire(PRODUCT_ID, 30, TimeUnit.SECONDS); ``` 此時，我們設定的過期時間為30秒。 那麼問題來了，這樣是否就真正的解決了問題呢？上述程式就真的沒有坑了嗎？**答案是還是有坑的！！** ### “坑位”分析 我們在下單操作的方法中為分散式鎖引入了超時機制，此時的程式碼還是無法真正避免死鎖的問題，那“坑位”到底在哪裡呢？試想，當程式執行完stringRedisTemplate.opsForValue().setIfAbsent()方法後，正要執行stringRedisTemplate.expire(PRODUCT_ID, 30, TimeUnit.SECONDS)程式碼時，伺服器宕機了，你還別說，生產壞境的情況非常複雜，就是這麼巧，伺服器就宕機了。此時，後續請求進入提交訂單的方法時，都會因為無法成功設定鎖標誌而導致後續下單流程無法正常執行。 既然我們找到了上述程式碼的“坑位”，那我們如何將這個”坑“填上？如何解決這個問題呢？別急，Redis已經提供了這樣的功能。我們可以在向Redis中儲存資料的時候，可以同時指定資料的超時時間。所以，我們可以將程式碼改造成如下所示。 ```java /** * 為了演示方便，我這裡就簡單定義了一個常量作為商品的id * 實際工作中，這個商品id是前端進行下單操作傳遞過來的引數 */ public static final String PRODUCT_ID = "100001"; @RequestMapping("/submitOrder") public String submitOrder(){ //通過stringRedisTemplate來呼叫Redis的SETNX命令，key為商品的id，value為字串“binghe” //實際上，value可以為任意的字元換 Boolean isLocked = stringRedisTemplate.opsForValue().setIfAbsent(PRODUCT_ID, "binghe", 30, TimeUnit.SECONDS); //沒有拿到鎖，返回下單失敗 if(!isLock){ return "failure"; } try{ int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock")); if(stock > 0){ stock -= 1; stringRedisTemplate.opsForValue().set("stock", String.valueOf(stock)); logger.debug("庫存扣減成功，當前庫存為：{}", stock); }else{ logger.debug("庫存不足，扣減庫存失敗"); throw new OrderException("庫存不足，扣減庫存失敗"); } }finally{ //業務執行完成，刪除PRODUCT_ID key stringRedisTemplate.delete(PRODUCT_ID); } return "success"; } ``` 在上述程式碼中，我們在向Redis中設定鎖標誌位的時候就設定了超時時間。此時，只要向Redis中成功設定了資料，則即使我們的業務系統宕機，Redis中的資料過期後，也會自動刪除。後續的執行緒進入提交訂單的方法後，就會成功的設定鎖標誌位，並向下執行正常的下單流程。 到此，上述的程式碼基本上在功能角度解決了程式的死鎖問題，那麼，上述程式真的就完美了嗎？哈哈，很多小夥伴肯定會說不完美！確實，上面的程式碼還不是完美的，那大家知道哪裡不完美嗎？接下來，我們繼續分析。 ### 在開發整合角度分析程式碼 在我們開發公共的系統元件時，比如我們這裡說的分散式鎖，我們肯定會抽取一些公共的類來完成相應的功能來供系統使用。 這裡，假設我們定義了一個RedisLock介面，如下所示。 ```java public interface RedisLock{ //加鎖操作 boolean tryLock(String key, long timeout, TimeUnit unit); //解鎖操作 void releaseLock(String key); } ``` 接下來，使用RedisLockImpl類實現RedisLock介面，提供具體的加鎖和解鎖實現，如下所示。 ```java public class RedisLockImpl implements RedisLock{ @Autowired private StringRedisTemplate stringRedisTemplate; @Override public boolean tryLock(String key, long timeout, TimeUnit unit){ return stringRedisTemplate.opsForValue().setIfAbsent(key, "binghe", timeout, unit); } @Override public void releaseLock(String key){ stringRedisTemplate.delete(key); } } ``` 在開發整合的角度來說，當一個執行緒從上到下執行時，首先對程式進行加鎖操作，然後執行業務程式碼，執行完成後，再進行釋放鎖的操作。理論上，加鎖和釋放鎖時，操作的Redis Key都是一樣的。但是，如果其他開發人員在編寫程式碼時，並沒有呼叫tryLock()方法，而是直接呼叫了releaseLock()方法，並且他呼叫releaseLock()方法傳遞的key與你呼叫tryLock()方法傳遞的key是一樣的。那此時就會出現問題了，他在編寫程式碼時，硬生生的將你加的鎖釋放了！！！ 所以，上述程式碼是不安全的，別人能夠隨隨便便的將你加的鎖刪除，這就是鎖的誤刪操作，這是非常危險的，所以，上述的程式存在很嚴重的問題！！ **那如何實現只有加鎖的執行緒才能進行相應的解鎖操作呢？** 繼續向下看。 ### 如何實現加鎖和解鎖的歸一化？ 什麼是加鎖和解鎖的歸一化呢？簡單點來說，就是一個執行緒執行了加鎖操作後，後續必須由這個執行緒執行解鎖操作，加鎖和解鎖操作由同一個執行緒來完成。 為了解決只有加鎖的執行緒才能進行相應的解鎖操作的問題，那麼，我們就需要將加鎖和解鎖操作繫結到同一個執行緒中，那麼，如何將加鎖操作和解鎖操作繫結到同一個執行緒呢？其實很簡單，相信很多小夥伴都想到了—— **使用ThreadLocal實現** 。沒錯，使用ThreadLocal類確實能夠解決這個問題。 此時，我們將RedisLockImpl類的程式碼修改成如下所示。 ```java public class RedisLockImpl implements RedisLock{ @Autowired private StringRedisTemplate stringRedisTemplate; private ThreadLocal