if（jedis.setnx(key_resource_id,lock_value) == 1）{ //加鎖
    expire（key_resource_id，100）; //設(shè)置過期時間
    try {
        do something  //業(yè)務(wù)請求
    }catch(){
  }
  finally {
       jedis.del(key_resource_id); //釋放鎖
    }
}

但是這個方案中，setnx和expire兩個命令分開了，不是原子操作。如果執(zhí)行完setnx加鎖，正要執(zhí)行expire設(shè)置過期時間時，進(jìn)程crash或者要重啟維護(hù)了，別的線程永遠(yuǎn)獲取不到鎖啦。

方案二：SETNX + value值是（系統(tǒng)時間+過期時間）

為了解決方案一發(fā)生異常鎖得不到釋放的場景，有小伙伴認(rèn)為，可以把過期時間放到setnx的value值里面。如果加鎖失敗，再拿出value值校驗一下即可。偽代碼如下：

long expires = System.currentTimeMillis() + expireTime; //系統(tǒng)時間+設(shè)置的過期時間
String expiresStr = String.valueOf(expires);

// 如果當(dāng)前鎖不存在，返回加鎖成功
if (jedis.setnx(key_resource_id, expiresStr) == 1) {
        return true;
} 
// 如果鎖已經(jīng)存在，獲取鎖的過期時間
String currentValueStr = jedis.get(key_resource_id);

// 如果獲取到的過期時間，小于系統(tǒng)當(dāng)前時間，表示已經(jīng)過期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {

     // 鎖已過期，獲取上一個鎖的過期時間，并設(shè)置現(xiàn)在鎖的過期時間（不了解redis的getSet命令的小伙伴，可以去官網(wǎng)看下哈）
    String oldValueStr = jedis.getSet(key_resource_id, expiresStr);
    
    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
         // 考慮多線程并發(fā)的情況，只有一個線程的設(shè)置值和當(dāng)前值相同，它才可以加鎖
         return true;
    }
}
        
//其他情況，均返回加鎖失敗
return false;
}

這個方案的優(yōu)點是，巧妙移除expire單獨設(shè)置過期時間的操作，把過期時間放到setnx的value值里面來。但是這個方案還有別的缺點：

過期時間是客戶端自己生成的（System.currentTimeMillis()是當(dāng)前系統(tǒng)的時間），必須要求分布式環(huán)境下，每個客戶端的時間必須同步。
如果鎖過期的時候，并發(fā)多個客戶端同時請求過來，都執(zhí)行jedis.getSet()，最終只能有一個客戶端加鎖成功，但是該客戶端鎖的過期時間，可能被別的客戶端覆蓋。
該鎖沒有保存持有者的唯一標(biāo)識，可能被別的客戶端釋放/解鎖。

方案三：使用Lua腳本(包含SETNX + EXPIRE兩條指令)

Redis 通過 LUA 腳本創(chuàng)建具有原子性的命令：當(dāng)lua腳本命令正在運行的時候，不會有其他腳本或 Redis 命令被執(zhí)行，實現(xiàn)組合命令的原子操作。

在Redis中執(zhí)行Lua腳本有兩種方法：eval和evalsha。eval命令使用內(nèi)置的 Lua 解釋器，對 Lua 腳本進(jìn)行求值，例子如下：

//第一個參數(shù)是lua腳本，第二個參數(shù)是鍵名參數(shù)個數(shù)，剩下的是鍵名參數(shù)和附加參數(shù)
> eval "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second
1) "key1"
2) "key2"
3) "first"
4) "second"

因此我們可以使用LUA腳本實現(xiàn)分布式鎖，偽代碼如下：

//LUA腳本
if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then
   redis.call('expire',KEYS[1],ARGV[2])
else
   return 0
end;

//加鎖
 String lua_scripts = "if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then" +
            " redis.call('expire',KEYS[1],ARGV[2]) return 1 else return 0 end";   
Object result = jedis.eval(lua_scripts, Collections.singletonList(key_resource_id), Collections.singletonList(values));
//判斷是否成功
return result.equals(1L);

方案四：SET的擴(kuò)展命令（SET EX PX NX）

Redis的SET指令擴(kuò)展參數(shù)也可以保證指令的原子性！

SET key value[EX seconds][PX milliseconds][NX|XX]
NX：表示key不存在的時候，才能set成功，也即保證只有第一個客戶端請求才能獲得鎖，而其他客戶端請求只能等其釋放鎖，才能獲取。
EX seconds：設(shè)定key的過期時間，時間單位是秒。
PX milliseconds：設(shè)定key的過期時間，單位為毫秒
XX：僅當(dāng)key存在時設(shè)置值

偽代碼如下：

if（jedis.set(key_resource_id, lock_value, "NX", "EX", 100s) == 1）{ //加鎖
    try {
        do something  //業(yè)務(wù)處理
    }catch(){
  }
  finally {
       jedis.del(key_resource_id); //釋放鎖
    }
}

但是呢，這個方案還是可能存在問題：

鎖過期釋放了，業(yè)務(wù)還沒執(zhí)行完。假設(shè)線程a獲取鎖成功，一直在執(zhí)行臨界區(qū)的代碼。但是100s過去后，它還沒執(zhí)行完。但是，這時候鎖已經(jīng)過期了，此時線程b又請求過來。顯然線程b就可以獲得鎖成功，也開始執(zhí)行臨界區(qū)的代碼。那么問題就來了，臨界區(qū)的業(yè)務(wù)代碼都不是嚴(yán)格串行執(zhí)行的啦。
鎖被別的線程誤刪。假設(shè)線程a執(zhí)行完后，去釋放鎖。但是它不知道當(dāng)前的鎖可能是線程b持有的（線程a去釋放鎖時，有可能過期時間已經(jīng)到了，此時線程b進(jìn)來占有了鎖）。那線程a就把線程b的鎖釋放掉了，但是線程b臨界區(qū)業(yè)務(wù)代碼可能都還沒執(zhí)行完呢。

方案五：SET EX PX NX + 校驗唯一隨機(jī)值,再釋放鎖

既然鎖可能被別的線程誤刪，那我們給value值設(shè)置一個標(biāo)記當(dāng)前線程唯一的隨機(jī)數(shù)，在刪除的時候，校驗一下，不就OK了嘛。偽代碼如下：

if（jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1）{ //加鎖
    try {
        do something  //業(yè)務(wù)處理
    }catch(){
  }
  finally {
       //判斷是不是當(dāng)前線程加的鎖,是才釋放
       if (uni_request_id.equals(jedis.get(key_resource_id))) {
        jedis.del(lockKey); //釋放鎖
        }
    }
}

在這里，判斷是不是當(dāng)前線程加的鎖和釋放鎖不是一個原子操作。這可能這把鎖已經(jīng)不屬于當(dāng)前客戶端，會解除他人加的鎖。

為了更嚴(yán)謹(jǐn)，一般也是用lua腳本代替。lua腳本如下：

if redis.call('get',KEYS[1]) == ARGV[1] then 
   return redis.call('del',KEYS[1]) 
else
   return 0
end;

方案六: 開源框架Redisson

方案五還是可能存在鎖過期釋放但業(yè)務(wù)沒執(zhí)行完的問題。為了解決這個問題，我們可以給獲得鎖的線程開啟一個定時守護(hù)線程，每隔一段時間檢查鎖是否還存在，存在則對鎖的過期時間延長，防止鎖過期提前釋放。

當(dāng)前開源框架Redisson就是這樣實現(xiàn)的，Redisson底層原理圖如下：

只要線程一加鎖成功，就會啟動一個watch dog看門狗，它是一個后臺線程，會每隔10秒檢查一下，如果線程1還持有鎖，那么就會不斷的延長鎖key的生存時間。因此，Redisson解決了鎖過期釋放但業(yè)務(wù)沒執(zhí)行完的問題。

方案七：多機(jī)實現(xiàn)的分布式鎖Redlock

前面六種方案都只是基于單機(jī)版的討論，還不是很完美。其實Redis一般都是集群部署的：

在這里插入圖片描述

如果線程一在Redis的master節(jié)點上拿到了鎖，但是加鎖的key還沒同步到slave節(jié)點。恰好這時，master節(jié)點發(fā)生故障，一個slave節(jié)點就會升級為master節(jié)點。線程二就可以獲取同個key的鎖啦，但線程一也已經(jīng)拿到鎖了，鎖的安全性就沒了。

為了解決這個問題，Redis提出一種高級的分布式鎖算法：Redlock。我們假設(shè)當(dāng)前有5個Redis master節(jié)點，在5臺服務(wù)器上面運行這些Redis實例，如下圖所示：

在這里插入圖片描述