1. Redis分布式鎖原理
1.1. Redisson
現在最流行的redis分布式鎖就是Redisson了，來看看它的底層原理就了解redis是如何使用分布式鎖的了
1.2. 原理分析
分布式鎖要解決的是分布式環境下，並行相同代碼的加鎖功能；了解過redis分布式鎖的人肯定知道，一開始redis作為分布式鎖用的是setnx，再這基礎上設置個定時過期時間，但這種方式有什么問題呢？
實際上看懂上圖的人也就明白了那有什么問題，首先是原子性問題，setnx+過期時間這兩個操作必須是原子性的，所以這可以用lua腳本解決
再然后是釋放鎖的時機該如何定？
- 不管我們定多少過期時間，都不能保證，在這段時間內鎖住的代碼執行完成了，所以這個時間定多少都不好；
- 如果不定時間，當執行完成后釋放鎖，問題就是如果執行到一半機器宕機，那這把鎖就永遠放不掉了
那Redisson是如何解決上述問題的呢？
- 它對代碼進行了精簡的封裝，我們的使用非常簡單，甚至我們不用主動設置過期時間
- 它設計了個watch dog看門狗，每隔10秒會檢查一下是否還持有鎖，若持有鎖，就給他更新過期時間30秒；通過這樣的設計，可以讓他在沒有釋放鎖之前一直持有鎖，哪怕宕機了，也能自動釋放鎖
- 而不能獲得鎖的客戶端則是不斷循環嘗試加鎖
- 通過記錄鎖的客戶端id，可以把它設計成可重入鎖
1.3. 存在問題
redis作為分布式鎖再大多數情況下是沒問題的，但是我們知道CAP原理，一致性，可用性，分區容錯性
在redis分布式架構中，我們其實保證的是AP模型，也就是盡可能的保證了redis的可用性，這在一般系統中當然是沒問題的，哪怕有時候一致性有點問題（實際讀到的數據不正確，或已經寫入沒讀到）畢竟是作為緩存的存在，一定延遲可以接受，沒讀到可以再讀數據庫，這是沒問題的。
但在分布式鎖中，一旦出現該讀到沒讀到，那就是重復鎖的問題了，相當於分布式鎖沒起到作用。
這種情況發生在什么時候呢？redis集群主節點再獲取鎖后，沒來得及復制數據給從節點，此時宕機了，從節點接替主節點進行讀寫，此時新的主節點沒有持有該鎖，那么其他想要獲取該鎖的服務也可以獲取到該鎖，導致了重復鎖的問題。
一般來講這種情況發生的概率是很小的，看你系統的規模而定，我覺得像阿里這種規模就應該不會用redis來作為分布式鎖了
CP模型的分布式鎖可以用zookeeper，可能性能略低於redis，但能保證安全，可以提供順序鎖等額外功能