基於Redission的分散式鎖實戰

2022-08-14 14:02:09

一、為什麼需要分散式鎖

在系統中，當存在多個程序和執行緒可以改變某個共用資料時，就容易出現並行問題導致共用資料的不一致性。

單體系統：如果多個執行緒要存取共用資源的時候，我們通常執行緒間加鎖的機制，在某一個時刻，只有一個執行緒可以對這個資源進行操作，其他執行緒需要等待鎖的釋放，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 分散式鎖內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！