一、為什么需要分布式鎖

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

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

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

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

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

2.1 Redission執(zhí)行流程

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

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

2.2 Watch Dog 機(jī)制

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

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

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

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

2.3 對比setnx

1、加鎖：使用setnx進(jìn)行加鎖，當(dāng)該指令返回1時(shí)，說明成功獲得鎖

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

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

（2）解決方案：設(shè)置鎖超時(shí)時(shí)間

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

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

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

4、使用set命令加鎖并設(shè)置鎖過期時(shí)間：

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

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

………………

如上總結(jié)下來，如果使用傳統(tǒng)的Redission的底層封裝相關(guān)的代碼幫助我們解決了一系列此問題

原子性 原子性 原子性

三、代碼案例

分享一下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在命令隊(duì)列層面還是單線程的, Redis在IO層面是做了多線程的優(yōu)化

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

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

最新評論