分布式鎖應(yīng)用場景

秒殺環(huán)境下：訂單服務(wù)從庫存中心拿到庫存數(shù)，如果庫存總數(shù)大于0，則進(jìn)行庫存扣減，并創(chuàng)建訂單
訂單服務(wù)負(fù)責(zé)創(chuàng)建訂單
庫存服務(wù)負(fù)責(zé)扣減庫存

模擬用戶訪問庫存

多線程并發(fā)訪問，出現(xiàn)超賣問題，線程不安全。沒有保證原子性

單體鎖的分類

單體應(yīng)用鎖指的是只能在 一個JVM 進(jìn)程內(nèi)有效的鎖。我們把這種鎖叫做單體應(yīng)用鎖

synchronized鎖ReentrantLock鎖
一個 Tomcat 可以看作是一個JVM進(jìn)程，當(dāng)大量請求并發(fā)到系統(tǒng)時，所有的請求都落在這唯一的一個Tomcat上，如果某些請求方法是需要加鎖的，比如：秒殺扣減庫存，是可以滿足需求的，但是隨著訪問量的增加，導(dǎo)致一個tomcat 難以支撐，這時我們必然就是集群部署Tomcat ，使用多個 Tomcat 共同支撐整個系統(tǒng)。

我們看到系統(tǒng)中存在兩個Tomcat，我們加的鎖是JDK提供的鎖，這種鎖只能在 一個JVM 下起到作用，也就是在一個Tomcat內(nèi)是沒有問題的。當(dāng)存在兩個或兩個以上的Tomcat時，大量的并發(fā)請求分散到不同的Tomcat上，在每一個Tomcat中都可以防止并發(fā)的產(chǎn)生，但是在多個Tomcat之間，每個Tomcat中獲得鎖的這個請求，又產(chǎn)生了并發(fā)，從而產(chǎn)生超賣現(xiàn)象。這也就是單體應(yīng)用鎖的局限性了，它只能在一個JVM內(nèi)加鎖，所以單體鎖只能鎖住單體環(huán)境，是鎖不住分布式環(huán)境或集群環(huán)境的。

分布式鎖核心邏輯

分布式鎖的核心邏輯就是在多個服務(wù)中設(shè)置一個公共的資源，在公共資源中設(shè)置鎖，供多個服務(wù)去同時搶奪鎖資源，一旦其中一個線程搶奪成功，其他線程就進(jìn)入自旋狀態(tài)，不同的嘗試訪問獲取鎖資源，在獲取鎖資源的線程執(zhí)行完相應(yīng)的邏輯以后就會釋放鎖資源，其他線程就可以獲取鎖資源。

分布式鎖實(shí)現(xiàn)的問題——死鎖和解決

死鎖：
如果某個線程在執(zhí)行鎖邏輯過程中宕機(jī)，導(dǎo)致沒有刪除鎖
解決：

添加過期時間

因?yàn)槭欠窃有蕴砑舆^期時間，可能導(dǎo)致在添加過期時間之前就出現(xiàn)宕機(jī)現(xiàn)象，此時依舊進(jìn)入死鎖狀態(tài)。原子性添加過期時間

Redis解決刪除別人鎖的問題

刪除別人鎖：
當(dāng)有線程A進(jìn)入后由于超時，有其他線程B進(jìn)入，此時redis中的鎖是線程B的，而原來的線程A接著執(zhí)行，線程A刪除了別人的鎖。

刪除別人鎖解決：
①給當(dāng)前線程綁定一個局部變量uuid,由于每個線程都有一份自己的局部變量，那么線程和局部變量綁定之后，我們在刪除鎖之前判斷一下，當(dāng)前這把鎖是不是自己的載進(jìn)行刪除
②使用lua表達(dá)式進(jìn)一步解決

上述方案還是存在問題，在線程A自己的uuid剛好與redis的uuid比較完,正準(zhǔn)備刪除的時候過期，這時候B線程進(jìn)入，此時的redisuuid就不是線程A的了，此時還是會存在刪除別人鎖的問題。
這是由于在拿鎖、比較鎖和刪除鎖的過程中并不是原子性的操作。解決此問題可以使用lua表達(dá)式

 到此這篇關(guān)于Redis分布式鎖解決秒殺超賣問題的文章就介紹到這了,更多相關(guān)Redis秒殺超賣內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論