普通實現
說道Redis分佈式鎖大部分人都會想到:setnx+lua，或者知道set key value px milliseconds nx。後一種方式的核心實現命令如下:
-獲取鎖(unique_value可以是UUID等) SET resource_name unique_value NX PX 30000 - 釋放鎖(lua腳本中，一定要比較value，防止誤解鎖) if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end
這種實現方式有3大要點(也是面試概率非常高的地方):
set命令要用set key value px milliseconds nx;value要具有唯一性;釋放鎖時要驗證value值，不能誤解鎖;
事實上這類瑣最大的缺點就是它加鎖時只作用在一個Redis節點上，即使Redis通過sentinel保證高可用，如果這個master節點由於某些原因發生了主從切換，那麼就會出現鎖丟失的情況:
在Redis的master節點上拿到了鎖;但是這個加鎖的key還沒有同步到slave節點;master故障，發生故障轉移，slave節點升級爲master節點;導致鎖丟失。
正因爲如此，Redis作者antirez基於分佈式環境下提出了一種更高級的分佈式鎖的實現方式:Redlock。筆者認爲，Redlock也是Redis所有分佈式鎖實現方式中唯一能讓面試官高潮的方式。
Redlock實現
antirez提出的redlock算法大概是這樣的:
在Redis的分佈式環境中，我們假設有N個Redis master。這些節點完全互相獨立，不存在主從複製或者其他集羣協調機制。我們確保將在N個實例上使用與在Redis單實例下相同方法獲取和釋放鎖。現在我們假設有5個Redis master節點，同時我們需要在5臺服務器上面運行這些Redis實例，這樣保證他們不會同時都宕掉。
爲了取到鎖，客戶端應該執行以下操作:
獲取當前Unix時間，以毫秒爲單位。依次嘗試從5個實例，使用相同的key和具有唯一性的value(例如UUID)獲取鎖。當向Redis請求獲取鎖時，客戶端應該設置一個網絡連接和響應超時時間，這個超時時間應該小於鎖的失效時間。例如你的鎖自動失效時間爲10秒，則超時時間應該在5-50毫秒之間。這樣可以避免服務器端Redis已經掛掉的情況下，客戶端還在死死地等待響應結果。如果服務器端沒有在規定時間內響應，客戶端應該儘快嘗試去另外一個Redis實例請求獲取鎖。客戶端使用當前時間減去開始獲取鎖時間(步驟1記錄的時間)就得到獲取鎖使用的時間。當且僅當從大多數(N/2+1，這裏是3個節點)的Redis節點都取到鎖，並且使用的時間小於鎖失效時間時，鎖纔算獲取成功。如果取到了鎖，key的真正有效時間等於有效時間減去獲取鎖所使用的時間(步驟3計算的結果)。如果因爲某些原因，獲取鎖失敗(沒有在至少N/2+1個Redis實例取到鎖或者取鎖時間已經超過了有效時間)，客戶端應該在所有的Redis實例上進行解鎖(即便某些Redis實例根本就沒有加鎖成功，防止某些節點獲取到鎖但是客戶端沒有得到響應而導致接下來的一段時間不能被重新獲取鎖)。Redlock源碼
redisson已經有對redlock算法封裝，接下來對其用法進行簡單介紹，並對核心源碼進行分析(假設5個redis實例)。
POM依賴 org.redisson redisson 3.3.2 用法
首先，我們來看一下redission封裝的redlock算法實現的分佈式鎖用法，非常簡單，跟重入鎖(ReentrantLock)有點類似:
Config config1 = new Config(); config1.useSingleServer().setAddress("redis://192.168.0.1:5378") .setPassword("a123456").setDatabase(0); RedissonClient redissonClient1 = Redisson.create(config1); Config config2 = new Config(); config2.useSingleServer().setAddress("redis://192.168.0.1:5379") .setPassword("a123456").setDatabase(0); RedissonClient redissonClient2 = Redisson.create(config2); Config config3 = new Config(); config3.useSingleServer().setAddress("redis://192.168.0.1:5380") .setPassword("a123456").setDatabase(0); RedissonClient redissonClient3 = Redisson.create(config3); String resourceName = "REDLOCK_KEY"; RLock lock1 = redissonClient1.getLock(resourceName); RLock lock2 = redissonClient2.getLock(resourceName); RLock lock3 = redissonClient3.getLock(resourceName); // 向3個redis實例嘗試加鎖 RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3); boolean isLock; try { // isLock = redLock.tryLock(); // 500ms拿不到鎖, 就認爲獲取鎖失敗。10000ms即10s是鎖失效時間。 isLock = redLock.tryLock(500, 10000, TimeUnit.MILLISECONDS); System.out.println("isLock = "+isLock); if (isLock) { //TODO if get lock success, do something; } } catch (Exception e) { } finally { // 無論如何, 最後都要解鎖 redLock.unlock(); }唯一ID
實現分佈式鎖的一個非常重要的點就是set的value要具有唯一性，redisson的value是怎樣保證value的唯一性呢?答案是UUID+threadId。入口在redissonClient.getLock("REDLOCK_KEY")，源碼在Redisson.java和RedissonLock.java中:
protected final UUID id = UUID.randomUUID(); String getLockName(long threadId) { return id + ":" + threadId; }獲取鎖
獲取鎖的代碼爲redLock.tryLock()或者redLock.tryLock(500, 10000, TimeUnit.MILLISECONDS)，兩者的最終核心源碼都是下面這段代碼，只不過前者獲取鎖的默認租約時間(leaseTime)是LOCK_EXPIRATION_INTERVAL_SECONDS，即30s:
RFuture tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand command) { internalLockLeaseTime = unit.toMillis(leaseTime); // 獲取鎖時需要在redis實例上執行的lua命令 return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command, // 首先分佈式鎖的KEY不能存在，如果確實不存在，那麼執行hset命令(hset REDLOCK_KEY uuid+threadId 1)，並通過pexpire設置失效時間(也是鎖的租約時間) "if (redis.call('exists', KEYS[1]) == 0) then " + "redis.call('hset', KEYS[1], ARGV[2], 1); " + "redis.call('pexpire', KEYS[1], ARGV[1]); " + "return nil; " + "end; " + // 如果分佈式鎖的KEY已經存在，並且value也匹配，表示是當前線程持有的鎖，那麼重入次數加1，並且設置失效時間 "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " + "redis.call('hincrby', KEYS[1], ARGV[2], 1); " + "redis.call('pexpire', KEYS[1], ARGV[1]); " + "return nil; " + "end; " + // 獲取分佈式鎖的KEY的失效時間毫秒數 "return redis.call('pttl', KEYS[1]);", // 這三個參數分別對應KEYS[1]，ARGV[1]和ARGV[2] Collections.singletonList(getName()), internalLockLeaseTime, getLockName(threadId)); }
獲取鎖的命令中，
KEYS[1]就是Collections.singletonList(getName())，表示分佈式鎖的key，即REDLOCK_KEY;ARGV[1]就是internalLockLeaseTime，即鎖的租約時間，默認30s;ARGV[2]就是getLockName(threadId)，是獲取鎖時set的唯一值，即UUID+threadId:釋放鎖
釋放鎖的代碼爲redLock.unlock()，核心源碼如下:
protected RFuture unlockInnerAsync(long threadId) { // 釋放鎖時需要在redis實例上執行的lua命令 return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN, // 如果分佈式鎖KEY不存在，那麼向channel發佈一條消息 "if (redis.call('exists', KEYS[1]) == 0) then " + "redis.call('publish', KEYS[2], ARGV[1]); " + "return 1; " + "end;" + // 如果分佈式鎖存在，但是value不匹配，表示鎖已經被佔用，那麼直接返回 "if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " + "return nil;" + "end; " + // 如果就是當前線程佔有分佈式鎖，那麼將重入次數減1 "local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " + // 重入次數減1後的值如果大於0，表示分佈式鎖有重入過，那麼只設置失效時間，還不能刪除 "if (counter > 0) then " + "redis.call('pexpire', KEYS[1], ARGV[2]); " + "return 0; " + "else " + // 重入次數減1後的值如果爲0，表示分佈式鎖只獲取過1次，那麼刪除這個KEY，併發布解鎖消息 "redis.call('del', KEYS[1]); " + "redis.call('publish', KEYS[2], ARGV[1]); " + "return 1; "+ "end; " + "return nil;", // 這5個參數分別對應KEYS[1]，KEYS[2]，ARGV[1]，ARGV[2]和ARGV[3] Arrays.asList(getName(), getChannelName()), LockPubSub.unlockMessage, internalLockLeaseTime, getLockName(threadId)); }
參考:https://redis.io/topics/distlock