個人理解是,雖然redis是單線程,但是可以同時有多個客戶端訪問,每個客戶端會有一個線程。客戶端訪問之間存在競爭。
因為存在多客戶端并發(fā),所以必須保證操作的原子性。比如銀行卡扣款問題,獲取余額,判斷,扣款,寫回就必須構(gòu)成事務(wù),否則就可能出錯。
在傳統(tǒng)單體應(yīng)用單機部署的情況下,可以使用Java并發(fā)相關(guān)的鎖,如ReentrantLcok或synchronized進行互斥控制。但是,隨著業(yè)務(wù)發(fā)展的需要,原單體單機部署的系統(tǒng),漸漸的被部署在多機器多JVM上同時提供服務(wù),這使得原單機部署情況下的并發(fā)控制鎖策略失效了,為了解決這個問題就需要一種跨JVM的互斥機制來控制共享資源的訪問,這就是分布式鎖要解決的問題。(推薦學(xué)習(xí):Redis視頻教程)
分布式鎖的實現(xiàn)條件
1、互斥性,和單體應(yīng)用一樣,要保證任意時刻,只能有一個客戶端持有鎖
2、可靠性,要保證系統(tǒng)的穩(wěn)定性,不能產(chǎn)生死鎖
3、一致性,要保證鎖只能由加鎖人解鎖,不能產(chǎn)生A的加鎖被B用戶解鎖的情況
redis實現(xiàn)分布式鎖不同的人可能有不同的實現(xiàn)邏輯。
分布式環(huán)境下,數(shù)據(jù)一致性問題一直是一個比較重要的話題,而又不同于單進程的情況。分布式與單機情況下最大的不同在于其不是多線程而是多進程。多線程由于可以共享堆內(nèi)存,因此可以簡單的采取內(nèi)存作為標記存儲位置。而進程之間甚至可能都不在同一臺物理機上,因此需要將標記存儲在一個所有進程都能看到的地方。
常見的是秒殺場景,訂單服務(wù)部署了多個實例。如秒殺商品有4個,第一個用戶購買3個,第二個用戶購買2個,理想狀態(tài)下第一個用戶能購買成功,第二個用戶提示購買失敗,反之亦可。而實際可能出現(xiàn)的情況是,兩個用戶都得到庫存為4,第一個用戶買到了3個,更新庫存之前,第二個用戶下了2個商品的訂單,更新庫存為2,導(dǎo)致出錯。
常見的鎖方案如下:
基于數(shù)據(jù)庫實現(xiàn)分布式鎖
基于緩存,實現(xiàn)分布式鎖,如redis
基于Zookeeper實現(xiàn)分布式鎖
更多Redis相關(guān)技術(shù)文章,請訪問Redis視頻教程欄目進行學(xué)習(xí)!