前言
近來,分佈式的問題被普遍說起,好比分佈式事務、分佈式框架、ZooKeeper、SpringCloud等等。本文先回顧鎖的概念,再介紹分佈式鎖,以及如何用Redis來實現分佈式鎖。面試
1、鎖的基本瞭解
首先,回顧一下咱們工做學習中的鎖的概念。數據庫
爲何要先講鎖再講分佈式鎖呢?
咱們都清楚,鎖的做用是要解決多線程對共享資源的訪問而產生的線程安全問題,而在平時生活中用到鎖的狀況其實並很少,可能有些朋友對鎖的概念和一些基本的使用不是很清楚,因此咱們先看鎖,再深刻介紹分佈式鎖。緩存
Redis分佈式鎖面試題答案地址:Redis分佈式面試題安全
經過一個賣票的小案例來看,好比你們去搶dota2 ti9門票,若是不加鎖的話會出現什麼問題?此時代碼以下:性能優化
**代碼分析:**這裏有8張ti9門票,設置了10個線程(也就是模擬10我的)去併發搶票,若是搶成功了顯示成功,搶失敗的話顯示失敗。按理說應該有8我的搶成功了,2我的搶失敗,下面來看運行結果:多線程
咱們發現運行結果和預期的狀況不一致,竟然10我的都買到了票,也就是說出現了線程安全的問題,那麼是什麼緣由致使的呢?併發
緣由就是多個線程之間產生了時間差。框架
如圖所示,只剩一張票了,可是兩個線程都讀到的票餘量是1,也就是說線程B尚未等到線程A改庫存就已經搶票成功了。分佈式
怎麼解決呢?想必你們都知道,加個synchronized關鍵字就能夠了,在一個線程進行reduce方法的時候,其餘線程則阻塞在等待隊列中,這樣就不會發生多個線程對共享變量的競爭問題。函數
舉個例子
好比咱們去健身房健身,若是好多人同時用一臺機器,同時在一臺跑步機上跑步,就會發生很大的問題,你們會打得不可開交。若是咱們加一把鎖在健身房門口,只有拿到鎖的鑰匙的人才能夠進去鍛鍊,其餘人在門外等候,這樣就能夠避免你們對健身器材的競爭。代碼以下:
運行結果:
果不其然,結果有兩我的沒有成功搶到票,看來咱們的目地達成了。
2、鎖的性能優化
2.1 縮短鎖的持有時間
事實上,按照咱們對平常生活的理解,不可能整個健身房只有一我的在運動。因此咱們只須要對某一臺機器加鎖就能夠了,好比一我的在跑步,另外一我的能夠去作其餘的運動。
對於票務系統來講,咱們只須要對庫存的修改操做的代碼加鎖就能夠了,別的代碼仍是能夠並行進行,這樣會大大減小鎖的持有時間,代碼修改以下:
這樣作的目的是充分利用cpu的資源,提升代碼的執行效率。
這裏咱們對兩種方式的時間作個打印:
果真,只對部分代碼加鎖會大大提供代碼的執行效率。
因此,在解決了線程安全的問題後,咱們還要考慮到加鎖以後的代碼執行效率問題。
2.2 減小鎖的粒度
舉個例子,有兩場電影,分別是最近剛上映的魔童哪吒和蜘蛛俠,咱們模擬一個支付購買的過程,讓方法等待,加了一個CountDownLatch的await方法,運行結果以下:
執行結果:
魔童哪吒的剩餘票數爲:20
咱們發現買哪吒票的時候阻塞會影響蜘蛛俠票的購買,而實際上,這兩場電影之間是相互獨立的,因此咱們須要減小鎖的粒度,將movie整個對象的鎖變爲兩個全局變量的鎖,修改代碼以下:
執行結果:
魔童哪吒的剩餘票數爲:20
蜘蛛俠的剩餘票數爲:100
如今兩場電影的購票不會互相影響了,這就是第二個優化鎖的方式:減小鎖的粒度。順便提一句,Java併發包裏的ConcurrentHashMap就是把一把大鎖變成了16把小鎖,經過分段鎖的方式達到高效的併發安全。
2.3 鎖分離
鎖分離就是常說的讀寫分離,咱們把鎖分紅讀鎖和寫鎖,讀的鎖不須要阻塞,而寫的鎖要考慮併發問題。
3、鎖的種類
- 公平鎖: ReentrantLock
- 非公平鎖: Synchronized、ReentrantLock、cas
- 悲觀鎖: Synchronized
- 樂觀鎖:cas
- 獨享鎖:Synchronized、ReentrantLock
- 共享鎖:Semaphore
這裏就不一一講述每一種鎖的概念了,你們能夠本身學習,鎖還能夠按照偏向鎖、輕量級鎖、重量級鎖來分類。
4、Redis分佈式鎖
瞭解了鎖的基本概念和鎖的優化後,重點介紹分佈式鎖的概念。
上圖所示是咱們搭建的分佈式環境,有三個購票項目,對應一個庫存,每個系統會有多個線程,和上文同樣,對庫存的修改操做加上鎖,能不能保證這6個線程的線程安全呢?
固然是不能的,由於每個購票系統都有各自的JVM進程,互相獨立,因此加synchronized只能保證一個系統的線程安全,並不能保證分佈式的線程安全。
因此須要對於三個系統都是公共的一箇中間件來解決這個問題。
這裏咱們選擇Redis來做爲分佈式鎖,多個系統在Redis中set同一個key,只有key不存在的時候,才能設置成功,而且該key會對應其中一個系統的惟一標識,當該系統訪問資源結束後,將key刪除,則達到了釋放鎖的目的。
4.1 分佈式鎖須要注意哪些點
1)互斥性
在任意時刻只有一個客戶端能夠獲取鎖。
這個很容易理解,全部的系統中只能有一個系統持有鎖。
2)防死鎖
假如一個客戶端在持有鎖的時候崩潰了,沒有釋放鎖,那麼別的客戶端沒法得到鎖,則會形成死鎖,因此要保證客戶端必定會釋放鎖。
Redis中咱們能夠設置鎖的過時時間來保證不會發生死鎖。
3)持鎖人解鎖
解鈴還須繫鈴人,加鎖和解鎖必須是同一個客戶端,客戶端A的線程加的鎖必須是客戶端A的線程來解鎖,客戶端不能解開別的客戶端的鎖。
4)可重入
當一個客戶端獲取對象鎖以後,這個客戶端能夠再次獲取這個對象上的鎖。
4.2 Redis分佈式鎖流程
Redis分佈式鎖的具體流程:
1)首先利用Redis緩存的性質在Redis中設置一個key-value形式的鍵值對,key就是鎖的名稱,而後客戶端的多個線程去競爭鎖,競爭成功的話將value設爲客戶端的惟一標識。Java學習圈子:14 201 9 080
2)競爭到鎖的客戶端要作兩件事:
- 設置鎖的有效時間 目的是防死鎖 (很是關鍵)
須要根據業務須要,不斷的壓力測試來決定有效期的長短。
- 分配客戶端的惟一標識,目的是保證持鎖人解鎖(很是重要)
因此這裏的value就設置成惟一標識(好比uuid)。
3)訪問共享資源
4)釋放鎖,釋放鎖有兩種方式,第一種是有效期結束後自動釋放鎖,第二種是先根據惟一標識判斷本身是否有釋放鎖的權限,若是標識正確則釋放鎖。
4.3 加鎖和解鎖
4.3.1 加鎖
1)setnx命令加鎖
set if not exists 咱們會用到Redis的命令setnx,setnx的含義就是隻有鎖不存在的狀況下才會設置成功。
2)設置鎖的有效時間,防止死鎖 expire
加鎖須要兩步操做,思考一下會有什麼問題嗎?
假如咱們加鎖完以後客戶端忽然掛了呢?那麼這個鎖就會成爲一個沒有有效期的鎖,接着就可能發生死鎖。雖然這種狀況發生的機率很小,可是一旦出現問題會很嚴重,因此咱們也要把這兩步合爲一步。
幸運的是,Redis3.0已經把這兩個指令合在一塊兒成爲一個新的指令。
來看jedis的官方文檔中的源碼:
這就是咱們想要的!
4.3.2 解鎖
- 檢查是否本身持有鎖(判斷惟一標識);
- 刪除鎖。
解鎖也是兩步,一樣也要保證解鎖的原子性,把兩步合爲一步。
這就沒法藉助於Redis了,只能依靠Lua腳原本實現。
這就是一段判斷是否本身持有鎖並釋放鎖的Lua腳本。
爲何Lua腳本是原子性呢?由於Lua腳本是jedis用eval()函數執行的,若是執行則會所有執行完成。
5、Redis分佈式鎖代碼實現
- 用一個上下文全局變量來記錄持有鎖的人的uuid,解鎖的時候須要將該uuid做爲參數傳入Lua腳本中,來判斷是否能夠解鎖。
- 要記錄當前線程,來實現分佈式鎖的重入性,若是是當前線程持有鎖的話,也屬於加鎖成功。
- 用eval函數來執行Lua腳本,保證解鎖時的原子性。
6、分佈式鎖的對比
6.1 基於數據庫的分佈式鎖
1)實現方式
獲取鎖的時候插入一條數據,解鎖時刪除數據。
2)缺點
- 數據庫若是掛掉會致使業務系統不可用。
- 沒法設置過時時間,會形成死鎖。
6.2 基於zookeeper的分佈式鎖
1)實現方式
加鎖時在指定節點的目錄下建立一個新節點,釋放鎖的時候刪除這個臨時節點。由於有心跳檢測的存在,因此不會發生死鎖,更加安全。
2)缺點
性能通常,沒有Redis高效。
因此:
- 從性能角度: Redis > zookeeper > 數據庫
- 從可靠性(安全)性角度: zookeeper > Redis > 數據庫
7、總結
本文從鎖的基本概念出發,提出多線程訪問共享資源會出現的線程安全問題,而後經過加鎖的方式去解決線程安全的問題,這個方法會性能會降低,須要經過:縮短鎖的持有時間、減少鎖的粒度、鎖分離三種方式去優化鎖。
更多Java面試資料共享地址:面試題資料合集
以後介紹了分佈式鎖的4個特色:
- 互斥性
- 防死鎖
- 加鎖人解鎖
- 可重入性
而後用Redis實現了分佈式鎖,加鎖的時候用到了Redis的命令去加鎖,解鎖的時候則藉助了Lua腳原本保證原子性。
最後對比了三種分佈式鎖的優缺點和使用場景。