基於Redission的分佈式鎖實戰

Posted on by

一、為什麼需要分佈式鎖

在系統中，當存在多個進程和線程可以改變某個共享數據時，就容易出現並發問題導致共享數據的不一致性。

單體系統：如果多個線程要訪問共享資源的時候，我們通常線程間加鎖的機制，在某一個時刻，隻有一個線程可以對這個資源進行操作，其他線程需要等待鎖的釋放，Java中也有一些處理鎖的機制，比如synchronized。

分佈式系統：當某個資源可以被多個系統訪問使用到的時候，為瞭保證大傢訪問這個數據是一致性的，那麼就要求再同一個時刻，隻能被一個系統使用，這時候線程之間的鎖機制就無法起到作用瞭，因為分佈式環境中，系統是會部署到不同的機器上面的，那麼就需要【分佈式鎖】瞭。

解決共享資源操作可能引發的數據問題

二、Redission的實戰使用

2.1 Redission執行流程

Redisson所有指令都通過lua腳本執行，redis支持lua腳本原子性執行

Redisson設置一個key的默認過期時間為30s,如果某個客戶端持有一個鎖超過瞭30s怎麼辦？

2.2 Watch Dog 機制

Redisson中有一個watchdog看門狗的概念，翻譯過來就是看門狗，它會在你獲取鎖之後，每隔10秒幫你把key的超時時間設為30s（默認配置）

這樣的話，就算一直持有鎖也不會出現key過期瞭，其他線程獲取到鎖的問題瞭。

Redisson的"看門狗"邏輯保證瞭沒有死鎖發生。

備註：如果機器宕機瞭，看門狗也就沒瞭。此時就不會延長key的過期時間，到瞭30s之後就會自動過期瞭，其他線程可以獲取到鎖

2.3 對比setnx

1、加鎖：使用setnx進行加鎖，當該指令返回1時，說明成功獲得鎖

2、解鎖：當得到鎖的線程執行完任務之後，使用del命令釋放鎖，以便其他線程可以繼續執行setnx命令來獲得鎖

（1）存在的問題：假設線程獲取瞭鎖之後，在執行任務的過程中掛掉，來不及顯示地執行del命令釋放鎖， 那麼競爭該鎖的線程都會執行不瞭，產生死鎖的情況。

（2）解決方案：設置鎖超時時間

3、設置鎖超時時間：setnx 的 key 必須設置一個超時時間，以保證即使沒有被顯式釋放，這把鎖也要在一定時間後自動釋放。可以使用expire命令設置鎖超時時間

（1）存在問題：setnx 和 expire 不是原子性的操作，假設某個線程執行setnx 命令，成功獲得瞭鎖， 但是還沒來得及執行expire 命令，服務器就掛掉瞭，這樣一來，這把鎖就沒有設置過期時間瞭，變成瞭死鎖，別的線程再也沒有辦法獲得鎖瞭。

（2）解決方案：redis的set命令支持在獲取鎖的同時設置key的過期時

4、使用set命令加鎖並設置鎖過期時間：

（1）存在問題：假如線程A成功得到瞭鎖，並且設置的超時時間是 30 秒。 如果某些原因導致線程 A 執行的很慢，過瞭 30 秒都沒執行完，這時候鎖過期自動釋放，線程 B 得到瞭鎖。

（2）解決方案：可以在 del 釋放鎖之前做一個判斷，驗證當前的鎖是不是自己加的鎖。 在加鎖的時候把當前的線程 ID 當做value，並在刪除之前驗證 key 對應的 value 是不是自己線程的 ID。 但是，這樣做其實隱含瞭一個新的問題，get操作、判斷和釋放鎖是兩個獨立操作，不是原子性。對於非原子性的問題，我們可以使用Lua腳本來確保操作的原子性

………………

如上總結下來，如果使用傳統的Redission的底層封裝相關的代碼幫助我們解決瞭一系列此問題

原子性 原子性 原子性

三、代碼案例

分享一下Redission的代碼使用案例：超簡單

引入pom.xml依賴

                <dependency>
			<groupId>org.redisson</groupId>
			<artifactId>redisson</artifactId>
			<version>3.6.5</version>
		</dependency>

模擬代碼

@RestController
public class IndexController {

    @Autowired
    private Redisson redisson;
    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    @RequestMapping("/deduct_stock")
    public String deductStock() {
        String lockKey = "product_101";
        RLock redissonLock = redisson.getLock(lockKey);
        try {
            //執行鎖
            redissonLock.lock();  //setIfAbsent(lockKey, clientId, 30, TimeUnit.SECONDS);
            int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock")); // jedis.get("stock")
            if (stock > 0) {
                int realStock = stock - 1;
                stringRedisTemplate.opsForValue().set("stock", realStock + ""); // jedis.set(key,value)
                System.out.println("扣減成功，剩餘庫存:" + realStock);
            } else {
                System.out.println("扣減失敗，庫存不足");
            }
        } finally {
            //釋放鎖
            redissonLock.unlock();
 
        }

        return "end";
    }

}

Redis在命令隊列層面還是單線程的, Redis在IO層面是做瞭多線程的優化

從上面的實現機制可以看出，Redis的多線程部分隻是用來處理網絡數據的讀寫和協議解析，執行命令仍然是單線程順序執行。所以我們不需要去考慮控制 key、lua、事務，LPUSH/LPOP 等等的並發及線程安全問題。

到此這篇關於基於Redission的分佈式鎖實戰的文章就介紹到這瞭,更多相關Redission 分佈式鎖內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：