#### 基於資料庫表樂觀鎖 (基本廢棄) 要實現分散式鎖，最簡單的⽅方式可能就是直接建立⼀一張鎖表，然後通過操作該表中的資料來實現了了。 當我們要鎖住某個⽅法或資源時，我們就在該表中增加一條記錄，想要釋放鎖的時候就刪除這條記錄。 比如建立這樣一張資料庫表: ``` CREATE TABLE `methodLock` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵', `method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '鎖定的⽅方法名', `desc` varchar(1024) NOT NULL DEFAULT '備註資訊', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '儲存資料時間，⾃自動⽣生成', PRIMARY KEY (`id`), UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='鎖定中的⽅方法'; ``` 當我們想要鎖住某個方法時，執行以下SQL: ``` insert into methodLock(method_name,desc) values (‘method_name’,‘desc’) ``` 因為我們對method_name做了唯一性約束，這里如果有多個請求同時提交到資料庫的話，資料庫會保證只有一個操作可以成功，那麼我們就可以認為操作成功的那個執行緒獲得了該方法的鎖，可以執方法體內容。 當⽅法執行完畢之後，想要釋放鎖的話，需要執⾏行行以下sql: ``` delete from methodLock where method_name ='method_name' ``` 上面說到這種方式基本廢棄，那麼這種簡單的實現會存在哪些問題呢？ 1. 這把鎖會強依賴資料庫的可用性，資料庫是一個單點，⼀旦資料庫掛掉，會導致業務系統不可⽤。 2. 這把鎖並沒有失效時間，⼀旦解鎖操作失敗，就會導致鎖記錄一直存在資料庫中，其它執行緒無法再獲得到鎖。 3. 這把鎖只能是非阻塞的，因為資料的insert操作，⼀旦插⼊入失敗就會直接報錯。沒有獲得鎖的執行緒並不會進入排隊列，要想再次獲得鎖就要再次觸發獲得鎖操作。 4. 這把鎖是非重⼊的，同⼀個執行緒在沒有釋放鎖之前無法再次獲得該鎖。因為資料已經存在了。當然，我們也可以有其它方式解決上面的問題。 - 針對資料庫是單點問題搞兩個資料庫，資料之前雙向同步。⼀旦掛掉快速切換到備庫上。 - 針對沒有失效時間?我們可以做一個定時任務，每隔一定時間把資料庫中的超時資料清理理一遍。 - 針對非阻塞的?搞⼀個自旋while迴圈，直到insert成功再返回成功。 - 針對⾮重入的?我們可以在資料庫表中加個欄位，記錄當前獲得鎖的機器的主機資訊和執行緒資訊，那麼下次再獲取鎖的時候先查詢資料庫，如果當前機器的主機資訊和執行緒資訊在資料庫可以查到的話，直接把鎖分配給他就可以了。 - 基於資料庫排他鎖 除了可以通過增刪操作資料表中的記錄以外，其實還可以藉助資料中自帶的鎖來實現分散式的鎖。我們⽤剛剛建立的那張資料庫表。可以通過資料庫的排他鎖來實現分散式鎖。 基於MySql的InnoDB 引擎，可以使用以下方法來實現加鎖操作。 虛擬碼如下： ``` public boolean lock(){ connection.setAutoCommit(false) while(true){ try{ result = select * from methodLock where method_name=xxx for update; if(result==null){ return true; } }catch(Exception e){ } sleep(1000); } return false; } ``` 在查詢語句後⾯增加for update，資料庫會在查詢過程中給資料庫表增加排他鎖。當某條記錄被加上排他鎖之後，其他執行緒將無法再在該行行記錄上增加排他鎖。 我們可以認為獲得排它鎖的執行緒即可獲得分散式鎖，當獲取到鎖之後，可以執⾏方法的業務邏輯，執行完之後，通過connection.commit()操作來釋放鎖。 這種方法可以有效的解決上⾯提到的⽆法釋放鎖和阻塞鎖的問題。 阻塞鎖? for update語句會在執行成功後⽴即返回，在執行失敗時⼀直處於阻塞狀態，直到成功。鎖定之後 服務宕機，⽆法釋放?使⽤這種⽅式，服務宕機之後資料庫會自己把鎖釋放掉。但是還是⽆法直接解決資料庫單點和可重⼊問題。 ``` public void unlock(){ connection.commit(); } ``` 說了這麼多，我們總結下資料庫方式實現。 ​ > 總結 這兩種方式都是依賴資料庫的一張表，一種是通過表中的記錄的存在情況確定當前是否有鎖存在，另外一種是通過資料庫的排他鎖來實現分散式鎖。 優點: 直接藉助資料庫，容易理解。 缺點: 會有各種各樣的問題，在解決問題的過程中會使整個⽅案變得越來越複雜。 操作資料庫需要一定的開銷，效能問題也需要考慮。 ​ #### Redis實現分散式鎖 redis實現分散式鎖在電商開發中是使用的較為成熟和普遍的一種方式，利用redis本身特性及鎖特性。如高效能(加、解鎖時高效能)，可以使用阻塞鎖與非阻塞鎖。不能出現死鎖。通過搭建redis叢集高可用性(不能出現節點 down 掉後加鎖失敗)。 嘗試寫虛擬碼增加理解，我們先看這種方式的分散式鎖如何搶佔。 ``` /** * @param key 鎖的key * @param lockValue 鎖的value * @param timeout 允許獲取鎖的時間，超過該時間就返回false * @param expire key的快取時間，也即一個執行緒⼀次持有鎖的時間， * @param sleepTime 獲取鎖的執行緒迴圈嘗試獲取鎖的間隔時間 * @return */ public boolean tryLock(String key, String lockValue, Integer timeout, Integer expire, Integer sleepTime) { int st = (sleepTime == null) ? DEFAULT_TIME : sleepTime; //允許獲取鎖的時間，預設30秒 int expiredNx = 30; final long start = System.currentTimeMillis(); if (timeout > expiredNx) { timeout = expiredNx; } final long end = start + timeout * 1000; // 預設返回失敗 boolean res ; //如果嘗試獲取鎖的時間超過了了允許時間，則直接返回 while (!(res = this.lock(key, lockValue, expire))) { if (System.currentTimeMillis() > end) { break; } try { // 執行緒sleep，避免過度請求Redis，該值可以調整 Thread.sleep(st); } catch (InterruptedException e) { ​ } } return res; } ``` 上⾯的討論中我們有一個⾮常重要的假設:Redis是單點的。如果Redis是叢集模式，我們考慮如下場景: 客戶端1和客戶端2同時持有了同一個資源的鎖，鎖不再具有安全性。根本原因是Redis叢集不是強⼀致性的。 那麼怎麼保證強⼀致性呢—**Redlock演算法** 假設客戶端1從Master獲取了鎖。 這時候Master宕機了，儲存鎖的key還沒有來得及同步到Slave上。 Slave升級為Master。 客戶端2從新的Master獲取到了對應同一個資源的鎖。 redLock實現步驟: 1. 客戶端獲取當前時間，以毫秒為單位。客戶端嘗試獲取N個節點的鎖，(每個節點獲取鎖的⽅式和前面說的快取鎖⼀樣)，N個節點以相同的 key和value獲取鎖。客戶端需要設定接⼝訪問超時，接⼝超時時間需要遠小於鎖超時時間，⽐如鎖⾃動釋放的時間是10s，那麼介面超時⼤概設定5-50ms。這樣可以在有redis節點宕機後，訪問該節點時能儘快超時，而減⼩鎖的正常使⽤。 3. 客戶端統計計算在獲得鎖的時候花費了多少時間，當前時間減去在獲取的時間，只有客戶端 獲得了超過3個節點的鎖，⽽且獲取鎖的時間⼩於鎖的超時時間，客戶端才獲得了了分散式鎖。 4. 客戶端獲取鎖的時間為設定的鎖超時時間減去步驟三計算出的獲取鎖花費時間。 5. 如果客戶端獲取鎖失敗了，客戶端會依次刪除所有的鎖。 使⽤用Redlock演算法，可以保證在掛掉最多2個節點的時候，分散式鎖服務仍然能⼯工作，這相比之前的資料庫鎖和快取鎖⼤大提高了可用性，由於redis的高效效能，分散式快取鎖效能並不比資料庫鎖差。 但是這種辦法就天衣無縫嗎？缺點在哪裡？ - 招架不住 Full GC 帶來的鎖超時問題，Redlock僅僅能相對提⾼可靠性。 假設客戶端1在獲得鎖之後發生了很長時間的GC pause，在此期間，它獲得的鎖過期了，⽽客戶端2獲得了鎖。當客戶端1從GC pause中恢復過來的時候，它不知道⾃己持有的鎖已經過期了，它依然發起了寫資料請求，⽽這時鎖實際上被客戶端2持有，因此兩個客戶端的寫請求就有可能衝突(鎖的互斥作⽤失效了)。 - 由於必須獲取到5個節點中的3個以上，所以可能出現獲取鎖衝突，即大家都獲得了1-2把鎖，結果誰也不能獲取到鎖，這個問題，redis作者借鑑了了raft演算法的精髓，通過沖突後在隨機時間開始，可以大大降低衝突時間，但是這問題並不能很好的避免，特別是在第⼀次獲取鎖的時候，所以獲取鎖的時間成本增加了了。如果5個節點有2個宕機，此時鎖的可用性會極大降低，⾸先必須等待這兩個宕機節點的結果超時才能返回，另外只有3個節點，客戶端必須獲取到這全部3個節點的鎖才能擁有鎖，難度也加⼤了。如果出現網路分割槽，那麼可能出現客戶端永遠也⽆法獲取鎖的情況。 > 優點:效能好 缺點:⽆法保證強⼀致性 (即能接受部分資料丟失) #### Zookeeper實現分散式鎖 **原理** 多個程序內同一時間都有執行緒在執行方法m，那麼鎖就一把，你獲得了鎖得以執行，我就得被阻塞，那你執行完了怎麼來喚醒我呢？因為你並不知道我被阻塞了，你也就不能通知我" 嗨，小橘，我用完了，你用吧 "。你能做的只有用的時候設定鎖標誌，用完了再取消你設定的標誌。我就必須在阻塞的時候隔一段時間主動去看看，但這樣總歸是有點麻煩的，最好有人來通知我可以執行了。 而zookeeper對於自身節點的兩大特性解決了這個問題 - 監聽者提供事件通知功能 - znode節點的不可重複特性 ​ **節點是什麼？** 節點是zookeeper中資料儲存的基礎結構，zk中萬物皆節點，就好比java中萬物皆物件是一樣的。zk的資料模型就是基於好多個節點的樹結構，但zk規定每個節點的引用規則是路徑引用。每個節點中包含子節點引用、儲存資料、訪問許可權以及節點元資料等四部分。 **zk中節點有型別區分嗎？** 有。zk中提供了四種類型的節點，各種型別節點及其區別如下： ​ 持久節點（PERSISTENT）：節點建立後，就一直存在，直到有刪除操作來主動清除這個節點 持久順序節點（PERSISTENT_SEQUENTIAL）：保留持久節點的特性，額外的特性是，每個節點會為其第一層子節點維護一個順序，記錄每個子節點建立的先後順序，ZK會自動為給定節點名加上一個數字字尾（自增的），作為新的節點名。 臨時節點（EPHEMERAL）：和持久節點不同的是，臨時節點的生命週期和客戶端會話繫結，當然也可以主動刪除。 臨時順序節點（EPHEMERAL_SEQUENTIAL）：保留臨時節點的特性，額外的特性如持久順序節點的額外特性。 ​ **如何操作節點？** 節點的增刪改查分別是create\delete\setData\getData，exists判斷節點是否存在，getChildren獲取所有子節點的引用。 ​ 上面提到了節點的監聽者，我們可以在對zk的節點進行查詢操作時，設定當前執行緒是否監聽所查詢的節點。getData、getChildren、exists都屬於對節點的查詢操作，這些方法都有一個boolean型別的watch引數，用來設定是否監聽該節點。一旦某個執行緒監聽了某個節點，那麼這個節點發生的creat（在該節點下新建子節點）、setData、delete（刪除節點本身或是刪除其某個子節點）都會觸發zk去通知監聽該節點的執行緒。但需要注意的是，執行緒對節點設定的監聽是一次性的，也就是說zk通知監聽執行緒後需要改執行緒再次設定監聽節點，否則該節點再次的修改zk不會再次通知。 **實現** - 方案一：使用節點中的儲存資料區域，zk中節點儲存資料的大小不能超過1M，但是隻是存放一個標識是足夠的。執行緒獲得鎖時，先檢查該標識是否是無鎖標識，若是可修改為佔用標識，使用完再恢復為無鎖標識。 ​ - 方案二：使用子節點，每當有執行緒來請求鎖的時候，便在鎖的節點下建立一個子節點，子節點型別必須維護一個順序，對子節點的自增序號進行排序，預設總是最小的子節點對應的執行緒獲得鎖，釋放鎖時刪除對應子節點便可。 ​ 兩種方案其實都是可行的，但是使用鎖的時候一定要去規避死鎖。方案一看上去是沒問題的，用的時候設定標識，用完清除標識，但是要是持有鎖的執行緒發生了意外，釋放鎖的程式碼無法執行，鎖就無法釋放，其他執行緒就會一直等待鎖，相關同步程式碼便無法執行。方案二也存在這個問題，但方案二可以利用zk的臨時順序節點來解決這個問題，只要執行緒發生了異常導致程式中斷，就會丟失與zk的連線，zk檢測到該連結斷開，就會自動刪除該連結建立的臨時節點，這樣就可以達到即使佔用鎖的執行緒程式發生意外，也能保證鎖正常釋放的目的。 那要是zk掛了怎麼辦？sad，zk要是掛了就沒轍了，因為執行緒都無法連結到zk，更何談獲取鎖執行同步程式碼呢。不過，一般部署的時候，為了保證zk的高可用，都會使用多個zk部署為叢集，叢集內部一主多從，主zk一旦掛掉，會立刻通過選舉機制有新的主zk補上。zk叢集掛了怎麼辦？不好意思，除非所有zk同時掛掉，zk叢集才會掛，概率超級小。 ``` /** * 嘗試加鎖 * @return */ public boolean tryLock() { // 建立臨時順序節點 if (this.currentPath == null) { // 在lockPath節點下面建立臨時順序節點 currentPath = this.client.createEphemeralSequential(LockPath + "/", "orangecsong"); } // 獲得所有的子節點