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

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

模擬用戶訪問庫存

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

單體鎖的分類

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

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

我們看到系統(tǒng)中存在兩個Tomcat，我們加的鎖是JDK提供的鎖，這種鎖只能在 一個JVM 下起到作用，也就是在一個Tomcat內(nèi)是沒有問題的。當存在兩個或兩個以上的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ù)去同時搶奪鎖資源，一旦其中一個線程搶奪成功，其他線程就進入自旋狀態(tài)，不同的嘗試訪問獲取鎖資源，在獲取鎖資源的線程執(zhí)行完相應(yīng)的邏輯以后就會釋放鎖資源，其他線程就可以獲取鎖資源。

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

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

添加過期時間

因為是非原子性添加過期時間，可能導致在添加過期時間之前就出現(xiàn)宕機現(xiàn)象，此時依舊進入死鎖狀態(tài)。原子性添加過期時間

Redis解決刪除別人鎖的問題

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

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

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

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

香港穩(wěn)定服務(wù)器

版權(quán)聲明：本站文章來源標注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學習參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。