分布式鎖
什么是分布式鎖？
為了實作分布式互斥，我們需要在某個地方做個標記，這個標記是每個執行緒都可以看到，當標記不存在時可以設定該標記，當標記被設定后，其他執行緒只能等待擁有該標記的執行緒執行完成，并釋放該標記后，才能去設定該標記和訪問共享資源，這里的標記就是我們討論的鎖，
鎖就是在多執行緒同時訪問同一資源的場景下，為了讓執行緒互不干擾地訪問共享資源，從而保證操作的有效性和正確性的一種標記，
分布式鎖是指在分布式環境下，系統部署在多個機器中，實作多行程分布式互斥的一種鎖，為了保證多個行程都可以看到鎖，鎖需要通過公共存盤來管理，這樣才能實作多個行程并發訪問同一個臨界資源，同一個時刻只有一個行程可訪問共享資源，確保資料的一致性，
我們在設計分布式鎖時要考慮的因素有哪些？
以下幾點需要考慮：
- 互斥性，對于某一共享資源，需要保證在同一時間只能有一個執行緒或行程對該資源進行操作，
- 具備鎖失效機制，防止死鎖，
- 可重入性，即行程未釋放鎖時，可以多次訪問臨界資源，
- 有高可用的獲取鎖和釋放鎖的功能，且性能要好，
常見的分布式鎖實作方法有哪些？
實作分布式鎖有3種主流的方法：
- 基于資料庫實作分布式鎖
- 基于快取實作分布式鎖
- 基于ZooKeeper實作分布式鎖
基于資料庫實作分布式鎖
基于資料庫實作分布式鎖比較簡單，主要在于創建一張鎖表，為申請者在鎖表中建立一條記錄，記錄建立成功則獲得鎖，消除記錄則釋放鎖，
因為需要頻繁訪問磁盤，IO開銷會比較大，因此這種方式適用于并發量低、對性能要求低的場景，
這種方式有兩個缺點：
- 單點故障問題，一旦資料庫不可用，會導致整個系統崩潰，
- 死鎖問題，資料庫鎖沒有失效時間，未獲得鎖的行程只能一致等待已獲得鎖的行程主動釋放鎖，如果已獲得共享資源訪問權限的行程忽然掛了，或者解鎖操作失敗，那么鎖記錄會一直存盤在資料庫中，無法洗掉，而其他行程也無法獲得鎖，從而造成死鎖，
基于快取實作分布式鎖
所謂基于快取，也就是說把資料存放在計算機記憶體中，不需要寫入磁盤，減少IO讀寫，
我們經常使用Redis來作為快取方案，使用setnx(key, value)函式實作分布式鎖，key和value就是基于快取的分布式鎖的兩個屬性，其中key表示鎖id，value=https://www.cnblogs.com/wing011203/p/currentTime + timeOut，表示當前時間+超時時間，
setnx函式的回傳值有0和1：
- 回傳1，說明該服務器獲得鎖，setnx將key對應的value設定為當前時間+鎖的有效時間
- 回傳0，說明其他服務已經獲得鎖，行程不能進入臨界區
Redis通過碎裂來維持行程訪問共享資源的先后順序，Redis鎖主要基于setnx函式實作分布式鎖，當行程通過setnx<key,value>函式回傳1時，表示已經獲得鎖，排在后面的行程只能等待前面的行程主動釋放鎖，或者等到時間超時才能獲得鎖，
這種方案的優點在于：
- 性能更好，訪問記憶體要比訪問磁盤快很多，
- 可以集群部署，避免了單點故障問題，
- 使用方便，很多快取服務都提供了可以用來實作分布式鎖的方法，
- 可以直接設定超時時間來控制鎖的釋放，
這種方案的缺點是通過超時時間來控制鎖的失效時間并不是十分可靠，因為一個行程執行時間可能比較長，或受系統行程做記憶體回收等影響，導致時間超時，從而不正確的釋放了鎖，
這種方案適用于高并發、對性能要求高的場景，
基于ZooKeeper的分布式鎖
ZooKeeper的樹形資料存盤結構主要由4種節點構成：
- 持久節點，默認節點型別，
- 持久順序節點，在創建節點時，ZooKeeper根據節點創建的時間順序對節點進行編號處理，
- 臨時節點，當客戶端與ZooKeeper斷開連接后，對應行程創建的臨時節點就會被洗掉，
- 臨時順序節點，按時間順序編號的臨時節點，
ZooKeeper基于臨時順序節點實作了分布鎖，
ZooKeeper實作分布式鎖的流程：
- 在持久節點shared_lock目錄下，為每個行程創建一個臨時順序節點，
- 每個行程獲取shared_lock目錄下的所有臨時節點串列，注冊Watcher，用于監聽子節點變更的資訊，當監聽到自己的臨時節點是順序最小的，則可以使用共享資源，
- 每個節點確定自己的編號是否是shared_lock下所有子節點中最小的，如果是最小的，就能獲得鎖，
- 如果行程對應的臨時節點編號不是最小的，那么有兩種情況：
- 本行程為讀請求，如果比自己序號小的節點中有寫請求，則等待，
- 本行程為寫請求，如果比自己序號小的節點中有請求，則等待，
使用ZooKeeper實作的分布式鎖，可以解決前兩種方法提到的各種問題，比如單點故障、不可重入、死鎖等，但是該方法實作比較復雜，且需要頻繁的添加和洗掉節點，所以性能不如基于快取實作的分布式鎖，
這種方案適用于大部分分布式場景，但是不適用于對性能要求極高的場景，
三種不同的分布式鎖，詳細的區別如下表所示，
分布式鎖中的羊群效應
所謂羊群效應，就是在整個ZooKeeper分布式鎖的競爭程序中，大量的行程都想要獲得鎖去使用共享資源，每個行程都有自己的Watcher來通知節點訊息，都會獲取整個子節點串列，使得資訊冗余，資源浪費，
當共享資源被解鎖后，ZooKeeper會通知所有監聽的行程，這些行程都會嘗試爭取鎖，但最終只能有一個行程獲得鎖，使得其他行程產生了大量的不必要的請求，造成了巨大的通信開銷，造成網路阻塞，性能下降，
如何解決？分為三步：
- 在與該方法對應的持久節點目錄下，為每個行程創建一個臨時順序節點，
- 每個行程獲取所有臨時節點串列，對比自己的編號是否最小，如最小，則獲得鎖，
- 若本行程對應的臨時節點編號不是最小的，則注冊Watcher，監聽自己的上一個臨時順序節點，當監聽到該節點釋放鎖后，則獲取鎖，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/543500.html
標籤：Java