}else {
//throw new RuntimeException("instance is error") ;
return false ;
}
if (UNLOCK_MSG.equals(result)){
return true ;
}else {
return false ;
}
}
這裡使用了一個 lua 腳本來判斷 value 是否相等，相等才執行 del 命令。
使用 lua 也可以保證這裡兩個操作的原子性。
因此上文提到的四個基本特性也能滿足了：
- 使用 Redis 可以保證性能。
- 阻塞鎖與非阻塞鎖見上文。
- 利用超時機制解決了死鎖。
- Redis 支持集群部署提高了可用性。
使用
我自己有擼了一個完整的實現，並且已經用於了生產，有興趣的朋友可以開箱使用:
maven 依賴：
1
2
3
4
5
配置 bean :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
@Configuration
public class RedisLockConfig {
@Bean
public RedisLock build(){
RedisLock redisLock = new RedisLock() ;
HostAndPort hostAndPort = new HostAndPort("127.0.0.1",7000) ;
JedisCluster jedisCluster = new JedisCluster(hostAndPort) ;
// Jedis 或 JedisCluster 都可以
redisLock.setJedisCluster(jedisCluster) ;
return redisLock ;
}
}
使用：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
@Autowired
private RedisLock redisLock ;
public void use() {
String key = "key";
String request = UUID.randomUUID().toString();
try {
boolean locktest = redisLock.tryLock(key, request);
if (!locktest) {
System.out.println("locked error");
return;
}
//do something
} finally {
redisLock.unlock(key,request) ;
}
}
使用很簡單。這裡主要是想利用 Spring 來幫我們管理 RedisLock 這個單例的 bean，所以在釋放鎖的時候需要手動(因為整個上下文只有一個 RedisLock 實例)的傳入 key 以及 request(api 看起來不是特別優雅)。
也可以在每次使用鎖的時候 new 一個 RedisLock 傳入 key 以及 request，這樣倒是在解鎖時很方便。但是需要自行管理 RedisLock 的實例。各有優劣吧。
項目源碼在：
https://github.com/crossoverJie/distributed-lock-redis
歡迎討論。
單測
在做這個項目的時候讓我不得不想提一下單測。
因為這個應用是強依賴於第三方組件的(Redis)，但是在單測中我們需要排除掉這種依賴。比如其他夥伴 fork 了該項目想在本地跑一遍單測，結果運行不起來：
- 有可能是 Redis 的 ip、端口和單測裡的不一致。
- Redis 自身可能也有問題。
- 也有可能是該同學的環境中並沒有 Redis。
所以最好是要把這些外部不穩定的因素排除掉，單測只測我們寫好的代碼。
於是就可以引入單測利器 Mock 了。
它的想法很簡答，就是要把你所依賴的外部資源統統屏蔽掉。如：數據庫、外部接口、外部文件等等。
使用方式也挺簡單，可以參考該項目的單測：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Test
public void tryLock() throws Exception {
String key = "test";
String request = UUID.randomUUID().toString();
Mockito.when(jedisCluster.set(Mockito.anyString(), Mockito.anyString(), Mockito.anyString(),
Mockito.anyString(), Mockito.anyLong())).thenReturn("OK");
boolean locktest = redisLock.tryLock(key, request);
System.out.println("locktest=" + locktest);
Assert.assertTrue(locktest);
//check
Mockito.verify(jedisCluster).set(Mockito.anyString(), Mockito.anyString(), Mockito.anyString(),
Mockito.anyString(), Mockito.anyLong());
}
這裡只是簡單演示下，可以的話下次仔細分析分析。
它的原理其實也挺簡單，debug 的話可以很直接的看出來：
這裡我們所依賴的 JedisCluster 其實是一個 cglib 代理對象。所以也不難想到它是如何工作的。
比如這裡我們需要用到 JedisCluster 的 set 函數並需要它的返回值。
Mock 就將該對象代理了，並在實際執行 set 方法後給你返回了一個你自定義的值。
這樣我們就可以隨心所欲的測試了，完全把外部依賴所屏蔽了。
總結
至此一個基於 Redis 的分佈式鎖完成，但是依然有些問題。
- 如在 key 超時之後業務並沒有執行完畢但卻自動釋放鎖了，這樣就會導致併發問題。
- 就算 Redis 是集群部署的，如果每個節點都只是 master 沒有 slave，那麼 master 宕機時該節點上的所有 key 在那一時刻都相當於是釋放鎖了，這樣也會出現併發問題。就算是有 slave 節點，但如果在數據同步到 salve 之前 master 宕機也是會出現上面的問題。
閱讀更多 JavaSpring高級進階 的文章
