面試連環炮系列（十九）：分佈式鎖的實現方案

1. 分佈式鎖的實現方案?
   相比單例鎖，分佈式鎖須要解決的問題：
   • 互斥性：任意時刻只能有一個客戶端擁有鎖，不能同時多個客戶端獲取。
   • 安全性：鎖只能被持有該鎖的用戶刪除，而不能被其餘用戶刪除。
   • 死鎖：獲取鎖的客戶端由於某些緣由而宕機，而未能釋放鎖，其餘客戶端沒法獲取此鎖，須要有機制來避免該類問題的發生。
   • 容錯：當部分節點宕機，客戶端仍能獲取鎖或者釋放鎖。

   經常使用的方案是基於Redis集羣的鎖實現，經常使用的Java組件是Redission。它對Redis分佈式鎖的實現很是完善，實現可重入鎖、讀寫鎖、公平鎖、信號量、CountDownLatch等不少種複雜的鎖的語義，知足咱們對分佈式鎖的不一樣層次的需求。

2. 主從模式下節點宕機可能致使鎖失效，Redission怎麼解決的
   Redission實現了Redlock算法解決這個問題。

3. 說說Redlock算法的原理
   假設咱們有5個Redis master實例：
   1. 客戶端獲取服務器當前的的時間t0，毫秒數。
   2. 使用相同的key和value依次向5個實例獲取鎖。客戶端在獲取鎖的時候自身設置一個遠小於業務鎖須要的持續時間的超時時間。舉個例子，假設鎖須要10秒，超時時間能夠設置成好比5-50毫秒。這個避免某個Redis自己已經掛了，可是客戶端一直在嘗試獲取鎖的狀況。超時了以後就直接跳到下一個節點。
   3. 客戶端經過當前時間（t1）減去t0，計算獲取鎖所消耗的時間t2（t1-t0)。只有t2小於鎖的業務有效時間(也就是第二步的10秒)，而且，客戶端在至少3(5/2+1)臺上獲取到鎖咱們才認爲鎖獲取成功。
   4. 若是鎖已經獲取，那麼鎖的業務有效時間爲10s-t2。
   5. 若是客戶端沒有獲取到鎖，多是沒有在大於等於N/2+1個實例上獲取鎖，也多是有效時間(10s-t2)爲負數，咱們就嘗試去釋放鎖，即便是並無在那個節點上獲取到。

4. Redlock算法有什麼缺點嗎？
   時間誤差在分佈式系統中很常見，在鎖有效時間裏雖然減去了時鐘偏移，可是這個值不太好肯定。Redis做者也建議對鎖互斥的安全性要求高的應用不要使用這個算法。

參考(部分摘抄的文字版權屬於原做者)：

https://www.jianshu.com/p/47fd7f86c848
https://www.jianshu.com/p/2d3bf2ff2315
http://www.javashuo.com/article/p-finiuwht-gu.html
http://www.javashuo.com/article/p-zqbofysm-gu.html