對於鎖大家肯定不會陌生，在 Java 中 synchronized 關鍵字和 ReentrantLock 可重入鎖在我們的程式碼中是經常見的，一般我們用其在多執行緒環境中控制對資源的併發訪問。

但是隨著分散式的快速發展，本地的加鎖往往不能滿足我們的需要，在我們的分散式環境中上面加鎖的方法就會失去作用。

於是人們為了在分散式環境中也能實現本地鎖的效果，也是紛紛各出其招，今天讓我們來聊一聊一般分散式鎖實現的套路。

為何需要分散式鎖

---

Martin Kleppmann 是英國劍橋大學的分散式系統的研究員，之前和 Redis 之父 Antirez 進行過關於 RedLock(紅鎖，後續有講到)是否安全的激烈討論。

Martin 認為一般我們使用分散式鎖有兩個場景：

• 效率：使用分散式鎖可以避免不同節點重複相同的工作，這些工作會浪費資源。比如使用者付了錢之後有可能不同節點會發出多封簡訊。

• 正確性：加分散式鎖同樣可以避免破壞正確性的發生，如果兩個節點在同一條資料上面操作，比如多個節點機器對同一個訂單操作不同的流程有可能會導致該筆訂單最後狀態出現錯誤，造成損失。

• 
  

分散式鎖的一些特點

---

當我們確定了在不同節點上需要分散式鎖，那麼我們需要了解分散式鎖到底應該有哪些特點？

分散式鎖的特點如下：

• 互斥性：和我們本地鎖一樣互斥性是最基本，但是分散式鎖需要保證在不同節點的不同執行緒的互斥。

• 可重入性：同一個節點上的同一個執行緒如果獲取了鎖之後那麼也可以再次獲取這個鎖。

• 鎖超時：和本地鎖一樣支援鎖超時，防止死鎖。

• 高效，高可用：加鎖和解鎖需要高效，同時也需要保證高可用防止分散式鎖失效，可以增加降級。

• 支援阻塞和非阻塞：和 ReentrantLock 一樣支援 lock 和 trylock 以及 tryLock(long timeOut)。

• 支援公平鎖和非公平鎖(可選)：公平鎖的意思是按照請求加鎖的順序獲得鎖，非公平鎖就相反是無序的。這個一般來說實現的比較少。

常見的分散式鎖

---

我們瞭解了一些特點之後，我們一般實現分散式鎖有以下幾個方式：

• MySQL

• ZK

• Redis

• 自研分散式鎖：如谷歌的 Chubby。

下面分開介紹一下這些分散式鎖的實現原理。

 MySQL 

首先來說一下 MySQL 分散式鎖的實現原理，相對來說這個比較容易理解，畢竟資料庫和我們開發人員在平時的開發中息息相關。

對於分散式鎖我們可以建立一個鎖表：

前面我們所說的 lock()，trylock(long timeout)，trylock() 這幾個方法可以用下面的虛擬碼實現。

lock()

lock 一般是阻塞式的獲取鎖，意思就是不獲取到鎖誓不罷休，那麼我們可以寫一個死迴圈來執行其操作：

mysqlLock.lcok 內部是一個 sql，為了達到可重入鎖的效果，我們應該先進行查詢，如果有值，需要比較 node_info 是否一致。

這裡的 node_info 可以用機器 IP 和執行緒名字來表示，如果一致就加可重入鎖 count 的值，如果不一致就返回 false。如果沒有值就直接插入一條資料。

虛擬碼如下：

需要注意的是這一段程式碼需要加事務，必須要保證這一系列操作的原子性。

tryLock() 和 tryLock(long timeout)

tryLock() 是非阻塞獲取鎖，如果獲取不到就會馬上返回，程式碼如下：

tryLock(long timeout) 實現如下：

mysqlLock.lock 和上面一樣，但是要注意的是 select … for update 這個是阻塞的獲取行鎖，如果同一個資源併發量較大還是有可能會退化成阻塞的獲取鎖。

unlock()

unlock 的話如果這裡的 count 為 1 那麼可以刪除，如果大於 1 那麼需要減去 1。

鎖超時

我們有可能會遇到我們的機器節點掛了，那麼這個鎖就不會得到釋放，我們可以啟動一個定時任務，通過計算一般我們處理任務的時間。

比如是 5ms，那麼我們可以稍微擴大一點，當這個鎖超過 20ms 沒有被釋放我們就可以認定是節點掛了然後將其直接釋放。

MySQL 小結：

• 適用場景：MySQL 分散式鎖一般適用於資源不存在資料庫，如果資料庫存在比如訂單，可以直接對這條資料加行鎖，不需要我們上面多的繁瑣的步驟。

• 比如一個訂單，我們可以用 select * from order_table where id = 'xxx' for update 進行加行鎖，那麼其他的事務就不能對其進行修改。

• 優點：理解起來簡單，不需要維護額外的第三方中介軟體(比如 Redis，ZK)。

• 缺點：雖然容易理解但是實現起來較為繁瑣，需要自己考慮鎖超時，加事務等等。效能侷限於資料庫，一般對比快取來說效能較低。對於高併發的場景並不是很適合。

樂觀鎖

前面我們介紹的都是悲觀鎖，這裡想額外提一下樂觀鎖，在我們實際專案中也是經常實現樂觀鎖，因為我們加行鎖的效能消耗比較大，通常我們對於一些競爭不是那麼激烈。

相關推薦