Redis實現分散式鎖的幾種方案

* GreatSQL社區原創內容未經授權不得隨意使用，轉載請聯系小編並注明來源。

1.前言

對於Redis實現分散式鎖的幾種方案這個話題，展開之前我想先簡單聊聊什麼是分散式鎖，分散式鎖的使用場景，除了Redis外還有什麼技術實現分散式鎖等一系列內容。

1.1分散式鎖

說大一點，就是在現在發展越來越迅速的大背景下，去中心化分散式系統越來越普及，在我們實際的生產開發當中，有一種不可避免的場景就是多個程式互斥的對其資源的使用，為了保證資料不重複，要求在同一時刻，同一任務只在一個節點上執行，且保證在多程式下的資料安全，分散式鎖就十分重要了。

1.2分散式鎖的幾種方案

方式有很多種，根據技術角度的不同

有基於MySQL的方式，透過表的唯一索引，透過insert和delete就可以實現加鎖和解鎖的效果；

有基於zookeeper的方式，透過建立臨時有序節點，判斷建立的節點序號是否最小。若是，則表示獲取到鎖，不是，則watch /lock目錄下序號比自身小的前一個節點，解鎖只需要刪除節點；

有基於Redis的方式。透過執行setnx，若成功再執行expire新增過期時間的方式加鎖，解鎖執行delete命令。

方式有很多，不一一列舉了。

1.3Redis分散式鎖需要滿足的條件

• 互斥性。在任意時刻，只有一個客戶端能持有鎖。
• 不發生死鎖。即使有一個客戶端在持有鎖的期間崩潰而沒有主動解鎖也能保證後續其他客戶端能加鎖。
• 同一性。加鎖和解鎖必須是同一個客戶端，客戶端自己不能把別人加的鎖給解了，即不能誤解鎖。
• 容錯性。只要大多數Redis節點正常執行，客戶端就能夠獲取和釋放鎖。

2.Redis實現分散式鎖的幾種方案

可以透過以下方式實現（包括但不限於）：

• SETNX + EXPIRE
• SETNX + value（系統時間+過期時間）
• 透過開源框架-Redisson

簡單來說說，用Java程式碼演示：

2.1 SETNX + EXPIRE

setnx（SET IF NOT EXISTS）+ expire命令。先用setnx來搶鎖，如果搶到鎖，再用expire給鎖設定一個過期時間，這樣持有鎖超時時釋放鎖，防止鎖忘記釋放。但此時setnx和expire兩個命令無法保證原子性，例如：

if（jedis.setnx(key_resource_id,lock_value) == 1）{ //加鎖
    expire（key_resource_id，100）; //設定過期時間
    try {
        //業務程式碼塊
    }catch() {
    }finally {
       jedis.del(key_resource_id); //釋放鎖
    }
}

2.2 SETNX + value（系統時間+過期時間）

可以把過期時間放到setnx的value值裡面。如果加鎖失敗，再拿出value值校驗一下即可。加鎖程式碼如下：

long expires = System.currentTimeMillis() + expireTime; //系統時間+設定的過期時間
String expiresStr = String.valueOf(expires);
// 如果當前鎖不存在，則加鎖成功
if (jedis.setnx(key_resource_id, expiresStr) == 1) {
        return true;
} 
// 如果鎖已經存在，獲取鎖的過期時間
String currentValueStr = jedis.get(key_resource_id);

// 如果獲取到的過期時間，小於系統當前時間，表示已經過期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
     // 鎖已過期，獲取上一個鎖的過期時間，並設定現在鎖的過期時間
    String oldValueStr = jedis.getSet(key_resource_id, expiresStr);
    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
         // 考慮多執行緒併發的情況，只有一個執行緒的設定值和當前值相同，它才可以加鎖
         return true;
    }
}
//其他情況均返回加鎖失敗
return false;

2.3 透過開源框架-Redisson

那麼此時就要去想了，如果已經超過了加鎖的過期時間，可是業務還沒執行完成，這個時候怎麼做呢？是把過期時間延長嗎？顯然不合理，可以透過開源框架-Redisson最佳化這個問題，簡單來說，Redisson就是當一個執行緒獲得鎖以後，給該執行緒開啟一個定時守護執行緒，每隔一段時間檢查鎖是否還存在，存在則對鎖的過期時間延長，防止鎖過期提前釋放。假設兩個執行緒爭奪統一公共資源：執行緒A獲取鎖，並透過雜湊演演算法選擇節點，執行Lua指令碼加鎖，同時其看門狗機制會啟動一個watch dog（後臺執行緒），每隔10秒檢查執行緒，如果執行緒A還持有鎖，那麼就會不斷的延長鎖key的生存時間。執行緒B獲得鎖失敗，就會訂閱解鎖訊息，當獲取鎖到剩餘過期時間後，呼叫訊號量方法阻塞住，直到被喚醒或等待超時。一旦執行緒A釋放了鎖，就會廣播解鎖訊息。於是，解鎖訊息的監聽器會釋放訊號量，獲取鎖被阻塞的執行緒B就會被喚醒，並重新嘗試獲取鎖。

Redisson 支援單點模式、主從模式、哨兵模式、叢集模式，假設現為單點模式：

//構造Config
Config config = new Config();
config.useSingleServer().setAddress("redis://ip:port").setPassword("Password.~#").setDatabase(0);
//構造RedissonClient
RedissonClient redissonClient = Redisson.create(config);
//獲取鎖例項
RLock rLock = redissonClient.getLock(lockKey);
try {
    //獲取鎖,waitTimeout為最大等待時間，超過這個值，則認為獲取鎖失敗。leaseTime為鎖的持有時間
    boolean res = rLock.tryLock((long)waitTimeout, (long)leaseTime, TimeUnit.SECONDS);
    if (res) {
        //業務塊
    }
} catch (Exception e) {
}finally{
    //解鎖
    rLock.unlock();
}

3.小結

Redis的分散式鎖實現方式有很多，這裡不一一列舉了，有機會再展開Lua指令碼、分散式鎖Redlock等內容。