前言

Java中的鎖主要包括synchronized鎖和JUC包中的鎖，這些鎖都是針對單個JVM實例上的鎖，對于分布式環(huán)境是無效的，那么基于分布式鎖的如何實現(xiàn)呢？

常見的分布式鎖的實現(xiàn)如下圖：

基于數(shù)據(jù)庫

悲觀鎖

悲觀鎖（Pessimistic Lock）顧名思義為很悲觀的鎖，每次在拿數(shù)據(jù)的時候都會上鎖。這樣別人想拿數(shù)據(jù)就被擋住，直到悲觀鎖被釋放，悲觀鎖中的共享資源每次只給一個線程使用，其它線程阻塞，用完后再把資源轉(zhuǎn)讓給其它線程，但是在效率方面，處理加鎖的機制會產(chǎn)生額外的開銷，且容易產(chǎn)生死鎖。

實現(xiàn)原理

悲觀并發(fā)控制實際上是"先取鎖再訪問"的保守策略，為數(shù)據(jù)處理的安全提供了保證.

具體實現(xiàn)

例如通過悲觀鎖來實現(xiàn)庫存扣減的偽代碼如下：

// 對于庫存記錄進行行鎖

SELECT *FROM sys_goods s WHERE s.Id='1' FOR UPDATE;

//執(zhí)行庫存扣減
update sys_stock　s set s.stockQty=s.stockQty-#{number} where s.goodId=1 and s.stockQty>0；

//提交事務(wù),自動釋放悲觀鎖。

樂觀鎖

簡介

樂觀鎖是基于數(shù)據(jù)版本號(version)的機制來實現(xiàn)的。數(shù)據(jù)庫表添加"version"字段, 讀取出數(shù)據(jù)時，將此版本號讀出，在更新過程中，會對版本號進行比較，如果是一致的，則會成功執(zhí)行本次操作,且版本號加1，如果版本號不一致，則會更新失敗。

實現(xiàn)原理

相對悲觀鎖，樂觀鎖的實現(xiàn)不會使用到數(shù)據(jù)庫的鎖機制，樂觀鎖的原理使用的CAS的機制來實現(xiàn)的，CAS(Compare-and-Swap)即比較并替換.

• 1、比較：讀取到了一個值A(chǔ)，在將其更新為B之前，檢查原值是否仍為A(未被其他線程改動).
• 2、設(shè)置：如果是未發(fā)送變化，則將A更新為B結(jié)束。如果發(fā)生變化，則什么都不做。

具體實現(xiàn)

例如樂觀鎖來實現(xiàn)庫存扣減的偽代碼如下：

// 查詢庫存記錄，獲取版本號
SELECT stockQty,version FROM sys_goods s WHERE s.Id='1'

//執(zhí)行庫存扣減，防止出現(xiàn)超賣
update sys_stock　s set 
  s.stockQty=s.stockQty-#{number},
  s.version=version+1
  where s.goodId=1 and s.stockQty>0 and version=#{version};

Redis實現(xiàn)分布式鎖

關(guān)于Redis分布式鎖的實現(xiàn)，已經(jīng)在前期的文章中進行了講解，大家可以參考如下文章

Spring Boot 實現(xiàn)Redis分布式鎖原理

Spring Boot 集成Redisson實現(xiàn)分布式鎖詳細案例

Zooker實現(xiàn)分布式鎖

Zookper實現(xiàn)分布式鎖，主要是應(yīng)用zookeeper節(jié)點的臨時和有序性來實現(xiàn)。

加鎖過程

當客戶端1請求時，Zookeeper客戶端會創(chuàng)建一個持久節(jié)點Locks節(jié)點，如果客戶端1想獲取鎖,會在locks節(jié)點下創(chuàng)建臨時節(jié)點/node_000000，如果查找Locks下面所有臨時有序子節(jié)點，當自己為最小的節(jié)點是則獲取鎖成功。

當客戶端2嘗試獲取鎖時，也會查看locks下面的臨時節(jié)點，判斷自己的節(jié)點/node_000001是不是最小，如果不是最小則獲取鎖失敗，客戶端2會向它排序靠前的節(jié)點node_000000注冊watch事件，用來監(jiān)聽node_000000是否存在，雖然搶鎖失敗，但是node_000001進入等待狀態(tài)。

釋放鎖的過程

Zookeeper的客戶端業(yè)務(wù)完成或者客戶端發(fā)生故障，都會刪除臨時節(jié)點并且釋放鎖。如果是任務(wù)完成，客戶端1還會顯式調(diào)用刪除node_000000的指令。

例如上述圖，客戶端1斷開，臨時節(jié)點node_000000已被刪除，而此時node_000001通過watcher監(jiān)聽發(fā)現(xiàn)自己為為最小的臨時節(jié)點，所以獲取鎖成功。

異常場景分析

客戶端1創(chuàng)建臨時節(jié)點后，會與Zookeeper服務(wù)器維護一個Session，這個Session會依賴客戶端 定時心跳來維持連接。由于網(wǎng)路異常原因，Zookeeper長時間收不到客戶端1的心跳，就認為這個Session過期了，也會把這個臨時節(jié)點刪除，此時客戶端2創(chuàng)建臨時節(jié)點能夠獲取鎖成功。當客戶端網(wǎng)絡(luò)恢復正常后，它仍然認為持有鎖，此時就會造成鎖沖突。

具體實現(xiàn)

Zookeeper實現(xiàn)分布式鎖，可以采用Curator實現(xiàn)分布式鎖，關(guān)于SpringBoot如何集成Curator，大家可以參考如下文章：

Java Spring Boot 集成Zookeeper

Zookpeer實現(xiàn)分布式鎖實現(xiàn)庫存扣減

 @RequestMapping("/lockStock")
    public void lockStock()
    {
       zooKeeperUtil.lock("/Locks", 1000, TimeUnit.SECONDS, ()->{
           //業(yè)務(wù)邏輯
       });
    }

小結(jié)：

關(guān)于分布式鎖的實現(xiàn)的對比，詳情請查看下圖：

總結(jié)

本文詳細的介紹了幾種分布式鎖的實現(xiàn)和使用，業(yè)務(wù)需要根據(jù)場景選擇合適的分布式鎖的實現(xiàn)，如有疑問，請隨時反饋。

到此這篇關(guān)于Redis常見分布鎖的原理和實現(xiàn)的文章就介紹到這了,更多相關(guān)Redis分布鎖原理內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論