| 與分布式鎖相對應的是「單機鎖」，我們在寫多線程程序時，避免同時操作一個共享變量產生數據問題，通常會使用一把鎖來「互斥」，以保證共享變量的正確性，其使用范圍是在「同一個進程」中。 |
在開始講分布式鎖之前，有必要簡單介紹一下，為什么需要分布式鎖?
與分布式鎖相對應的是「單機鎖」，我們在寫多線程程序時，避免同時操作一個共享變量產生數據問題，通常會使用一把鎖來「互斥」，以保證共享變量的正確性，其使用范圍是在「同一個進程」中。
如果換做是多個進程，需要同時操作一個共享資源，如何互斥呢?
例如，現在的業務應用通常都是微服務架構，這也意味着一個應用會部署多個進程，那這多個進程如果需要修改 MySQL 中的同一行記錄時，為了避免操作亂序導致數據錯誤，此時，我們就需要引入「分布式鎖」來解決這個問題了。
想要實現分布式鎖，必須借助一個外部系統，所有進程都去這個系統上申請「加鎖」。
而這個外部系統，必須要實現「互斥」的能力，即兩個請求同時進來，只會給一個進程返回成功，另一個返回失敗(或等待)。
這個外部系統，可以是 MySQL，也可以是 Redis 或 Zookeeper。但為了追求更好的性能，我們通常會選擇使用 Redis 或 Zookeeper 來做。
下面我就以 Redis 為主線，由淺入深，帶你深度剖析一下，分布式鎖的各種「安全性」問題，幫你徹底理解分布式鎖。
我們從最簡單的開始講起。
想要實現分布式鎖，必須要求 Redis 有「互斥」的能力，我們可以使用 SETNX 命令，這個命令表示SET if Not eXists，即如果 key 不存在，才會設置它的值，否則什么也不做。
兩個客戶端進程可以執行這個命令，達到互斥，就可以實現一個分布式鎖。
客戶端 1 申請加鎖，加鎖成功：
127.0.0.1:6379> SETNX lock 1 (integer) 1 // 客戶端1，加鎖成功
客戶端 2 申請加鎖，因為后到達，加鎖失敗：
127.0.0.1:6379> SETNX lock 1 (integer) 0 // 客戶端2，加鎖失敗
此時，加鎖成功的客戶端，就可以去操作「共享資源」，例如，修改 MySQL 的某一行數據，或者調用一個 API 請求。
操作完成后，還要及時釋放鎖，給后來者讓出操作共享資源的機會。如何釋放鎖呢?
也很簡單，直接使用 DEL 命令刪除這個 key 即可：
127.0.0.1:6379> DEL lock // 釋放鎖 (integer) 1
這個邏輯非常簡單，整體的路程就是這樣：
但是，它存在一個很大的問題，當客戶端 1 拿到鎖后，如果發生下面的場景，就會造成「死鎖」：
程序處理業務邏輯異常，沒及時釋放鎖
進程掛了，沒機會釋放鎖
這時，這個客戶端就會一直占用這個鎖，而其它客戶端就「永遠」拿不到這把鎖了。
怎么解決這個問題呢?
我們很容易想到的方案是，在申請鎖時，給這把鎖設置一個「租期」。
在 Redis 中實現時，就是給這個 key 設置一個「過期時間」。這里我們假設，操作共享資源的時間不會超過 10s，那么在加鎖時，給這個 key 設置 10s 過期即可：
127.0.0.1:6379> SETNX lock 1 // 加鎖 (integer) 1 127.0.0.1:6379> EXPIRE lock 10 // 10s后自動過期 (integer) 1
這樣一來，無論客戶端是否異常，這個鎖都可以在 10s 后被「自動釋放」，其它客戶端依舊可以拿到鎖。
疑問臉，但這樣真的沒問題嗎?
還是有問題。
現在的操作，加鎖、設置過期是 2 條命令，有沒有可能只執行了第一條，第二條卻「來不及」執行的情況發生呢?例如：
- SETNX 執行成功，執行 EXPIRE 時由於網絡問題，執行失敗
- SETNX 執行成功，Redis 異常宕機，EXPIRE 沒有機會執行
- SETNX 執行成功，客戶端異常崩潰，EXPIRE 也沒有機會執行
總之，這兩條命令不能保證是原子操作(一起成功)，就有潛在的風險導致過期時間設置失敗，依舊發生「死鎖」問題。
在 Redis 2.6.12 版本之前，我們需要想盡辦法，保證 SETNX 和 EXPIRE 原子性執行，還要考慮各種異常情況如何處理。
但在 Redis 2.6.12 之后，Redis 擴展了 SET 命令的參數，用這一條命令就可以了：
// 一條命令保證原子性執行 127.0.0.1:6379> SET lock 1 EX 10 NX OK
這樣就解決了死鎖問題，也比較簡單。