Redis分散式鎖服務
概述
在多執行緒環境下，通常會使用鎖來保證有且只有一個執行緒來操作共享資源。比如：
object obj = new object();
lock (obj)
{
//操作共享資源
}
利用作業系統提供的鎖機制，可以確保多執行緒或多程序下的併發唯一操作。但如果在多機環境下就不能滿足了，當A，B兩臺機器同時操作C機器的共享資源時，就需要第三方的鎖機制來保證在分散式環境下的資源協調，也稱分散式鎖。
Redis有三個最基本屬性來保證分散式鎖的有效實現：
- 安全性： 互斥，在任何時候，只有一個客戶端能持有鎖。
- 活躍性A：沒有死鎖，即使客戶端在持有鎖的時候崩潰，最後也會有其他客戶端能獲得鎖，超時機制。
- 活躍性B：故障容忍，只有大多數Redis節點時存活的，客戶端仍可以獲得鎖和釋放鎖。
分散式鎖
由於Redis是單執行緒模型，命令操作原子性，所以利用這個特性可以很容易的實現分散式鎖。 獲得一個鎖
SET key uuid NX PX timeout SET resource_name uniqueVal NX PX 30000
命令中的NX表示如果key不存在就新增，存在則直接返回。PX表示以毫秒為單位設定key的過期時間，這裡是30000ms。 設定過期時間是防止獲得鎖的客戶端突然崩潰掉或其他異常情況，導致redis中的物件鎖一直無法釋放，造成死鎖。
Key的值需要在所有請求鎖服務的客戶端中，確保是個唯一值。 這是為了保證拿到鎖的客戶端能安全釋放鎖，防止這個鎖物件被其他客戶端刪除。
舉個例子：
- A客戶端拿到物件鎖，但在因為一些原因被阻塞導致無法及時釋放鎖。
- 因為過期時間已到，Redis中的鎖物件被刪除。
- B客戶端請求獲取鎖成功。
- A客戶端此時阻塞操作完成，刪除key釋放鎖。
- C客戶端請求獲取鎖成功。
- 這時B、C都拿到了鎖，因此分散式鎖失效。
要避免例子中的情況發生，就要保證key的值是唯一的，只有拿到鎖的客戶端才能進行刪除。 基於這個原因，普通的del命令是不能滿足要求的，我們需要一個能判斷客戶端傳過來的value和鎖物件的value是否一樣的命令。遺憾的是Redis並沒有這樣的命令，但可以通過Lua指令碼來完成：
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
邏輯很簡單，獲取key中的值和引數中的值相比較，相等刪除，不相等返回0。
多例項分散式鎖
上面是在單個Redis例項實現分散式鎖的，這存在一個問題就是，如果這臺例項因某些原因崩潰掉，那麼所有客戶端的鎖服務全部失效。
Redis本身支援Master-Slave結構，可以一主多從，採用高可用方法，可以保證在master掛的時候自動切換到slave。 但是由於主從之間是非同步同步資料的，所以redis並不能完全的實現鎖的安全性。 舉個例子來說：
- A客戶端在master例項上獲得一個鎖。
- 在物件鎖key傳送到slave之前，master崩潰掉。
- 一個slave被選舉成master。
- B客戶端可以獲取到同個key的鎖，但A也已經拿到鎖，導致鎖失效。
在多臺master情況下實現這個演算法，並保證鎖的安全性。 步驟如下：
- 客戶端以毫秒為單位獲取當前時間。
- 使用同樣key和值，迴圈在多個例項中獲得鎖。 為了獲得鎖，客戶端應該設定個偏移時間，它小於鎖自動釋放時間(即key的過期時間)。 舉個例子來說，如果一個鎖自動釋放時間是10秒，那偏移時間應該設定在5~50毫秒的範圍。 防止因為某個例項崩潰掉或其他原因，導致client在獲取鎖時耗時過長。
- 計算獲取所有鎖的耗時，即當前時間減去開始時間，得到a值。 用鎖自動釋放時間減去a值，在減去偏移時間，得到c值，如果獲取鎖成功的例項數量大於實際的數量一半，並且c大於0，那麼鎖就被獲取成功。
- 鎖獲取成功，鎖物件的有效時間是上面的c值。
- 若是客戶端因為一些原因獲取失敗，原因可能是上面的c值為負數或者鎖成功的數量小於例項數，以用N/2+1當標準(N為例項數)。 那麼會釋放所有例項上的鎖。
上面描述可能不方便理解，用程式碼表示如下：
//鎖自動釋放時間
TimeSpan ttl=new TimeSpan(0,0,0,30000)
//獲取鎖成功的數量
int n = 0;
//記錄開始時間
var startTime = DateTime.Now;
//在每個例項上獲取鎖
for_each_redis(
redis =>
{
if (LockInstance(redis, resource, val, ttl)) n += 1;
}
);
//偏移時間是鎖自動釋放時間的1%，根據上面10s是5-50毫秒推出。
var drift = Convert.ToInt32(ttl.TotalMilliseconds * 0.01);
//鎖物件的有效時間=鎖自動釋放時間-(當前時間-開始時間)-偏移時間
var validity_time = ttl - (DateTime.Now - startTime) - new TimeSpan(0, 0, 0, 0, drift);
//判斷成功的數量和有效時間c值是否大於0 if (n >= (N/2+1) && validity_time.TotalMilliseconds > 0) { }
總結
用Redis做分散式鎖相比其他分散式鎖(zookeeper)實現更簡單，速度更快。
在ServiceStack.Redis客戶端元件上是直接支援鎖實現的。
或者用stackexchange客戶端元件，鎖實現及示例程式碼： https://github.com/kidfashion/redlock-cs 。
官方介紹文件： http://redis.io/topics/distlock 。
本文的重點是你有沒有收穫與成長，其餘的都不重要，希望讀者們能謹記這一點。同時我經過多年的收藏目前也算收集到了一套完整的學習資料，包括但不限於：分散式架構、高可擴充套件、高效能、高併發、Jvm效能調優、Spring，MyBatis，Nginx原始碼分析，Redis，ActiveMQ、、Mycat、Netty、Kafka、Mysql、Zookeeper、Tomcat、Docker、Dubbo、Nginx等多個知識點高階進階乾貨，希望對想成為架構師的朋友有一定的參考和幫助
喜歡這篇文章的朋友可以點個喜歡，也可以關注一下我的個人專題：Java成長之路
需要更詳細思維導圖和以下資料的可以加一下技術交流分享群：“708 701 457”免費獲取
