redis中的分布式鎖
分布式鎖的實現場景
在平時的開發中，對於高並發的開發場景，我們不可避免要加鎖進行處理，當然redis中也是不可避免的，下面是我總結出來的幾種鎖的場景
Redis分布式鎖方案一
使用Redis實現分布式鎖最簡單的方案是在獲取鎖之前先查詢一下以該鎖為key對應的value存不存在，如果存在，則說明該鎖被其他客戶端獲取了，否則的話就嘗試獲取鎖，獲取鎖的方法很簡單，只要以該鎖為key，設置一個隨機的值就行了。比如，我們現在有個秒殺的場景，並發量可能是3000，但是我們商品的庫存數量是一定的，為了防止超賣，我們就需要在減庫存的時候加上鎖，當第一個請求過來的時候，先判斷鎖時候存在，不存在就加鎖，然後去處理秒殺的業務，並且在處理完成的時候，釋放鎖，如果判斷鎖存在，就輪訓等待鎖被釋放。
缺點
1、如果我們處理業務的時候報錯了，那麽加上的鎖就不能及時被釋放了，這時候我們需要加上一個異常的捕獲，在finally的時候釋放鎖。
2、同時我們也要主要set寫入key，是會出現覆蓋操作的，我們要要註意使用setnx（只要鎖被加上，後面的寫入操作不會覆蓋前面的寫入）
2、但是，有可能我們在處理業務的時候，整個服務器碟機了，那麽異常的捕獲顯眼是不管用了，這時候我們的這種設計顯然是存在缺陷的。
Redis分布式鎖方案二
上一節的方案缺點就是鎖有時候沒有辦法釋放，造成死鎖。那麽對於setnx我們應該怎樣處理呢？
考慮一種情況，如果進程獲得鎖後，斷開了與 Redis 的連接（可能是進程掛掉，或者網絡中斷），如果沒有有效的釋放鎖的機制，那麽其他進程都會處於一直等待的狀態，即出現“死鎖”。
上面在使用 SETNX 獲得鎖時，我們將鍵 lock.foo 的值設置為鎖的有效時間，進程獲得鎖後，其他進程還會不斷的檢測鎖是否已超時，如果超時，那麽等待的進程也將有機會獲得鎖。
然而，鎖超時時，我們不能簡單地使用 DEL 命令刪除鍵 lock.foo 以釋放鎖。考慮以下情況，進程P1已經首先獲得了鎖 lock.foo，然後進程P1掛掉了。進程P2，P3正在不斷地檢測鎖是否已釋放或者已超時，執行流程如下：
- P2和P3進程讀取鍵 lock.foo 的值，檢測鎖是否已超時（通過比較當前時間和鍵 lock.foo 的值來判斷是否超時）
- P2和P3進程發現鎖 lock.foo 已超時
- P2執行 DEL lock.foo命令
- P2執行 SETNX lock.foo命令，並返回1，即P2獲得鎖
- P3執行 DEL lock.foo命令將P2剛剛設置的鍵 lock.foo 刪除（這步是由於P3剛才已檢測到鎖已超時）
- P3執行 SETNX lock.foo命令，並返回1，即P3獲得鎖
- P2和P3同時獲得了鎖
從上面的情況可以得知，在檢測到鎖超時後，進程不能直接簡單地執行 DEL 刪除鍵的操作以獲得鎖。
為了解決上述算法可能出現的多個進程同時獲得鎖的問題，我們再來看以下的算法。
我們同樣假設進程P1已經首先獲得了鎖 lock.foo，然後進程P1掛掉了。接下來的情況：
- 進程P4執行 SETNX lock.foo 以嘗試獲取鎖
- 由於進程P1已獲得了鎖，所以P4執行 SETNX lock.foo 返回0，即獲取鎖失敗
- P4執行 GET lock.foo 來檢測鎖是否已超時，如果沒超時，則等待一段時間，再次檢測
- 如果P4檢測到鎖已超時，即當前的時間大於鍵 lock.foo 的值，P4會執行以下操作
GETSET lock.foo <current Unix timestamp + lock timeout + 1> - 由於 GETSET 操作在設置鍵的值的同時，還會返回鍵的舊值，通過比較鍵 lock.foo 的舊值是否小於當前時間，可以判斷進程是否已獲得鎖
- 假如另一個進程P5也檢測到鎖已超時，並在P4之前執行了 GETSET 操作，那麽P4的 GETSET 操作返回的是一個大於當前時間的時間戳，這樣P4就不會獲得鎖而繼續等待。註意到，即使P4接下來將鍵 lock.foo 的值設置了比P5設置的更大的值也沒影響。
另外，值得註意的是，在進程釋放鎖，即執行 DEL lock.foo 操作前，需要先判斷鎖是否已超時。如果鎖已超時，那麽鎖可能已由其他進程獲得，這時直接執行 DEL lock.foo 操作會導致把其他進程已獲得的鎖釋放掉。
缺點
1、其實這種方案還存在缺陷，我們知道對於鎖設置過期的時間，雖然可以解決鎖的及時釋放，但是我們知道我們需要處理的業務場景的時間的不可控，可能網絡動蕩，我們原來0.01秒的業務現在就需要3秒鐘，所以簡單的對鎖設置過期的時間，還是存在缺陷的。
Redis分布式鎖方案三
那麽對於方案二的場景的缺點我們應該怎麽去處理呢？有一個簡單的方法就是當給一個鎖加上過期的時間的時候，我們另外開啟一個線程，去監測業務處理的時間，如果鎖額時間快到了，並且業務還沒有執行完畢，就給鎖的時間延長，實現自旋的加鎖。
redis中的分布式鎖