Redis分散式鎖如何實現 ?
在Redis中提供了一個命令setnx(SET ifnot exists)
由於Redis的單執行緒的，用了命令之後，只能有一個客戶端對某一個key設定值，在沒有過期或刪除key的時候是其他客戶端是不能設定這個key的。
如何控制Redis實現分散式鎖有效時長呢?
Redis的setnx指令不好控制這個問題，我們當時採用的Redis的一個框架redisson實現的。
在redisson中需要手動加鎖，並且可以控制鎖的失效時間和等待時間，當鎖住的一個業務還沒有執行完成的時候，在redisson中引入了一個看門狗Watch Dog機制，就是說每隔一段時間就檢查當前業務是否還持有鎖，如果持有就增加加鎖的持有時間，當業務執行完成之後需要使用釋放鎖就可以了。
還有一個好處就是，在高併發下，一個業務有可能會執行很快，先客戶1持有鎖的時候，客戶2來了以後並不會馬上拒絕，它會自選不斷嘗試獲取鎖，如果客戶1釋放之後，客戶2就可以馬上持有鎖，效能也得到了提升。
redisson實現的分散式鎖是可重入的嗎?
候選人:嗯，是可以重入的。這樣做是為了避免死鎖的產生。這個重入其實在內部就是判斷是否是當前執行緒持有的鎖，如果是當前執行緒持有的鎖就會計數，如果釋放鎖就會在計算上減一。在儲存資料的時候採用的hash結構，大key可以按照自己的業務進行定製，其中小key是當前執行緒的唯一標識，val是當前執行緒重入的次數
redisson實現的分散式鎖能解決主從一致性的問題嗎
這個是不能的，比如，當執行緒1加鎖成功後，master節點資料會非同步複製到slave節點，此時當前持有Redis鎖的master節點當機，slave節點被提升為新的master節點，假如現在來了一個執行緒2，再次獲取鎖，由於新的master節點沒有同步舊master節點的資料，導致執行緒1和執行緒2同時擁有一個鎖。
但是可以使用redisson提供的紅鎖來解決，但是這樣的話，效能就太低了，如果業務中非要保證資料的強一致性，建議採用ZooKeeper實現的分散式鎖。Redis滿足AP思想，而ZooKeeper滿足CP思想。
CAP原則
CAP原則又稱CAP定理，指的是在一個分散式系統中，一致性（Consistency）、可用性（Availability）、分割槽容錯性（Partition tolerance），但是CAP 原則指示3個要素最多隻能同時實現兩點，不可能三者兼顧，由於網路硬體肯定會出現延遲丟包等問題，但是在分散式系統中，我們必須保證部分網路通訊問題不會導致整個伺服器叢集癱瘓，另外即使分成了多個區，當網路故障消除的時候，我們依然可以保證資料一致性，所以我們必須保證分割槽容錯性。
至於剩下的一致性和可用性，我們需要二選一，但是魚和熊掌不可兼得，假設我們選擇一致性，那我們就不能讓使用者訪問無法進行資料同步的機器，畢竟該機器上的資料和其他正常機器上的不一致，但是這樣我們就丟棄了可用性；假設我們選擇可用性，那我們就可以讓使用者訪問無法進行資料同步的伺服器，雖然保證了可用性，但是我們無法保證資料一致性。