個人理解是，雖然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í)！
