一、為什么需要分布式鎖

在系統(tǒng)中，當存在多個進程和線程可以改變某個共享數(shù)據(jù)時，就容易出現(xiàn)并發(fā)問題導致共享數(shù)據(jù)的不一致性。

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

分布式系統(tǒng)：當某個資源可以被多個系統(tǒng)訪問使用到的時候，為了保證大家訪問這個數(shù)據(jù)是一致性的，那么就要求再同一個時刻，只能被一個系統(tǒng)使用，這時候線程之間的鎖機制就無法起到作用了，因為分布式環(huán)境中，系統(tǒng)是會部署到不同的機器上面的，那么就需要【分布式鎖】了。

解決共享資源操作可能引發(fā)的數(shù)據(jù)問題

二、Redission的實戰(zhàn)使用

2.1 Redission執(zhí)行流程

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

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

2.2 Watch Dog 機制

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

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

Redisson的"看門狗"邏輯保證了沒有死鎖發(fā)生。

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

2.3 對比setnx

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

2、解鎖：當?shù)玫芥i的線程執(zhí)行完任務之后，使用del命令釋放鎖，以便其他線程可以繼續(xù)執(zhí)行setnx命令來獲得鎖

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

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

3、設置鎖超時時間：setnx 的 key 必須設置一個超時時間，以保證即使沒有被顯式釋放，這把鎖也要在一定時間后自動釋放?？梢允褂胑xpire命令設置鎖超時時間

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

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

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

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

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

………………

如上總結下來，如果使用傳統(tǒng)的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 {
            //執(zhí)行鎖
            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層面是做了多線程的優(yōu)化

從上面的實現(xiàn)機制可以看出，Redis的多線程部分只是用來處理網(wǎng)絡數(shù)據(jù)的讀寫和協(xié)議解析，執(zhí)行命令仍然是單線程順序執(zhí)行。所以我們不需要去考慮控制 key、lua、事務，LPUSH/LPOP 等等的并發(fā)及線程安全問題。

到此這篇關于基于Redission的分布式鎖實戰(zhàn)的文章就介紹到這了,更多相關Redission 分布式鎖內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論