一、為什么需要分布式鎖

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

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

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

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

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

2.1 Redission執(zhí)行流程

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

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

2.2 Watch Dog 機(jī)制

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

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

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

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

2.3 對(duì)比setnx

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

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

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

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

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

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

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

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

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

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

………………

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

原子性 原子性 原子性

三、代碼案例

分享一下Redission的代碼使用案例：超簡(jiǎn)單

引入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("扣減成功，剩余庫(kù)存:" + realStock);
            } else {
                System.out.println("扣減失敗，庫(kù)存不足");
            }
        } finally {
            //釋放鎖
            redissonLock.unlock();
 
        }

        return "end";
    }

}

Redis在命令隊(duì)列層面還是單線程的, Redis在IO層面是做了多線程的優(yōu)化

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

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

最新評(píng)論