糾正誤區(qū):這才是 SpringBoot Redis 分布式鎖的正確實(shí)現(xiàn)方式
我是碼哥,可以叫我靚仔。
在說(shuō)分布式鎖之前,我們先說(shuō)下為什么需要分布式鎖。
在單機(jī)部署的時(shí)候,我們可以使用 Java 中提供的 JUC 鎖機(jī)制避免多線(xiàn)程同時(shí)操作一個(gè)共享變量產(chǎn)生的安全問(wèn)題。JUC 鎖機(jī)制只能保證同一個(gè) JVM 進(jìn)程中的同一時(shí)刻只有一個(gè)線(xiàn)程操作共享資源。
一個(gè)應(yīng)用部署多個(gè)節(jié)點(diǎn),多個(gè)進(jìn)程如果要修改同一個(gè)共享資源,為了避免操作亂序?qū)е碌牟l(fā)安全問(wèn)題,這個(gè)時(shí)候就需要引入分布式鎖,分布式鎖就是用來(lái)控制同一時(shí)刻,只有一個(gè) JVM 進(jìn)程中的一個(gè)線(xiàn)程可以訪(fǎng)問(wèn)被保護(hù)的資源。
分布式鎖很重要,然而很多公司的系統(tǒng)可能還在跑著有缺陷的分布式鎖方案,其中不乏一些大型公司。
所以,碼哥今天分享一個(gè)正確 Redis 分布式鎖代碼實(shí)戰(zhàn),讓你一飛沖天,該代碼可直接用于生產(chǎn),不是簡(jiǎn)單的 demo。
溫馨提示:如果你只想看代碼實(shí)戰(zhàn)部分,可直接翻到 SpringBoot 實(shí)戰(zhàn)章節(jié)。
錯(cuò)誤的分布式鎖
說(shuō)正確方案之前,先來(lái)一個(gè)錯(cuò)誤的,知道錯(cuò)在哪,才能意識(shí)到如何寫(xiě)正確。
在銀行工作的小白老師,使用 Redis SET 指令實(shí)現(xiàn)加鎖, 指令滿(mǎn)足了當(dāng) key 不存在則設(shè)置 value,同時(shí)設(shè)置超時(shí)時(shí)間,并且滿(mǎn)足原子語(yǔ)意。
SET lockKey 1 NX PX expireTime
- lockKey 表示鎖的資源,value 設(shè)置成 1。
- NX:表示只有 lockKey 不存在的時(shí)候才能 SET 成功,從而保證只有一個(gè)客戶(hù)端可以獲得鎖。
- PX expireTime設(shè)置鎖的超時(shí)時(shí)間,單位是毫秒;也可以使用 EX seconds以秒為單位設(shè)置超時(shí)時(shí)間。
至于解鎖操作,小白老師果決的使用 DEL指令刪除。一個(gè)分布式鎖方案出來(lái)了,一氣呵成,組員不明覺(jué)厲,紛紛豎起大拇指,偽代碼如下。
//加鎖成功
if(jedis.set(lockKey, 1, "NX", "EX", 10) == 1){
try {
do work //執(zhí)行業(yè)務(wù)
} finally {
//釋放鎖
jedis.del(key);
}
}
然而,這是一個(gè)錯(cuò)誤的分布式鎖。問(wèn)題在于解鎖的操作有可能出現(xiàn)釋放別人的鎖的情況。
有可能出現(xiàn)釋放別人的鎖的情況。
- 客戶(hù)端 A 獲取鎖成功,設(shè)置超時(shí)時(shí)間 10 秒。
- 客戶(hù)端 A 執(zhí)行業(yè)務(wù)邏輯,但是因?yàn)槟承┰颍ňW(wǎng)絡(luò)問(wèn)題、FullGC、代碼垃圾性能差)執(zhí)行很慢,時(shí)間超過(guò) 10 秒,鎖因?yàn)槌瑫r(shí)自動(dòng)釋放了。
- 客戶(hù)端 B 加鎖成功。
- 客戶(hù)端 A 執(zhí)行 DEL 釋放鎖,相當(dāng)于把客戶(hù)端 B 的鎖釋放了。
原因很簡(jiǎn)單:客戶(hù)端加鎖時(shí),沒(méi)有設(shè)置一個(gè)唯一標(biāo)識(shí)。釋放鎖的邏輯并不會(huì)檢查這把鎖的歸屬,直接刪除。
殘血版分布式鎖
小白老師:“碼哥,怎么解決釋放別人的鎖的情況呢?”
解決方法:客戶(hù)端加鎖時(shí)設(shè)置一個(gè)“唯一標(biāo)識(shí)”,可以讓 value 存儲(chǔ)客戶(hù)端的唯一標(biāo)識(shí),比如隨機(jī)數(shù)、 UUID 等;釋放鎖時(shí)判斷鎖的唯一標(biāo)識(shí)與客戶(hù)端的標(biāo)識(shí)是否匹配,匹配才能刪除。
加鎖
SET lockKey randomValue NX PX 3000
解鎖
刪除鎖的時(shí)候判斷唯一標(biāo)識(shí)是否匹配偽代碼如下。
if (jedis.get(lockKey).equals(randomValue)) {
jedis.del(lockKey);
}
加鎖、解鎖的偽代碼如下所示。
try (Jedis jedis = pool.getResource()) {
//加鎖成功
if(jedis.set(lockKey, randomValue, "NX", "PX", 3000) == 1){
do work //執(zhí)行業(yè)務(wù)
}
} finally {
//判斷是不是當(dāng)前線(xiàn)程加的鎖,是才釋放
if (randomValue.equals(jedis.get(keylockKey {
jedis.del(lockKey); //釋放鎖
}
}
到這里,很多公司可能都是使用這個(gè)方式來(lái)實(shí)現(xiàn)分布式鎖。
小白:“碼哥,還有問(wèn)題。判斷鎖的唯一標(biāo)識(shí)是否與當(dāng)前客戶(hù)端匹配和刪除操作不是原子操作?!?/p>
聰明。這個(gè)方案還存在原子性問(wèn)題,存在其他客戶(hù)端把鎖給釋放的問(wèn)題。
- 客戶(hù)端 A 執(zhí)行唯一標(biāo)識(shí)匹配成功,還來(lái)不及執(zhí)行DEL釋放鎖操作,鎖過(guò)期被釋放。
- 客戶(hù)端 B 獲取鎖成功,value 設(shè)置了自己的客戶(hù)端唯一標(biāo)識(shí)。
- 客戶(hù)端 A 繼續(xù)執(zhí)行 DEL刪除鎖操作,相當(dāng)于把客戶(hù)端 B 的鎖給刪了。
青銅版分布式鎖
雖然叫青銅版,這也是我們最常用的分布式鎖方案之一了,這個(gè)版本沒(méi)有太大的硬傷,并且比較簡(jiǎn)單。
小白老師:“碼哥,這如何是好,如何解決解鎖不是原子操作的問(wèn)題?分布式鎖這么多門(mén)道,是我膚淺了。”
解決方案很簡(jiǎn)單,解鎖的邏輯我們可以通過(guò) Lua 腳本來(lái)實(shí)現(xiàn)判斷和刪除的過(guò)程。
- KEYS[1]是 lockKey。
- ARGV[1] 表示客戶(hù)端的唯一標(biāo)識(shí) requestId。
返回 nil 表示鎖不存在,已經(jīng)被刪除了。只有返回值是 1 才表示加鎖成功。
// key 不存在,返回 null
if (redis.call('exists', KEYS[1]) == 0) then
return nil;
end;
// 獲取 KEY[1] 中的 value 與 ARGV[1] 匹配,匹配則 del,返回 1。不匹配 return 0 解鎖失敗
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1]);
else
return 0;
end;
使用上面的腳本,每個(gè)鎖都用一個(gè)隨機(jī)值作為唯一標(biāo)識(shí),當(dāng)刪除鎖的客戶(hù)端的“唯一標(biāo)識(shí)”與鎖的 value 匹配的時(shí)候,才能執(zhí)行刪除操作。這個(gè)方案已經(jīng)相對(duì)完美,我們用的最多的可能就是這個(gè)方案了。
理論知識(shí)學(xué)完了,上實(shí)戰(zhàn)。
Spring Boot 環(huán)境準(zhǔn)備
接下來(lái)碼哥,給你一個(gè)基于 Spring Boot 并且能用于生產(chǎn)實(shí)戰(zhàn)的代碼。在上實(shí)戰(zhàn)代碼之前,先把 Spring Boot 集成 Redis 的環(huán)境搞定。
添加依賴(lài)
代碼基于 Spring Boot 2.7.18 ,使用 lettuce 客戶(hù)端來(lái)操作 Redis。添加 spring-boot-starter-data-redis依賴(lài)。
<dependencyManagement>
<dependencies>
<dependency>
<!-- Import dependency management from Spring Boot -->
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>2.7.18</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.28</version>
<optional>true</optional>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<!--redis依賴(lài)-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<!--Jackson依賴(lài)-->
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
SpringBoot 配置
先配置 yaml。
server:
servlet:
context-path: /redis
port: 9011
spring:
application:
name: redis
redis:
host: 127.0.0.1
port: 6379
password: magebyte
timeout: 6000
client-type: lettuce
lettuce:
pool:
max-active: 300
max-idle: 100
max-wait: 1000ms
min-idle: 5
RedisTemplate 默認(rèn)序列化方式不具備可讀性,我們改下配置,使用 JSON 序列化。注意了,這一步是附加操作,與分布式鎖沒(méi)有關(guān)系,是碼哥順帶給你的彩蛋。
@Configuration
public class RedisConfig {
@Bean
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory connectionFactory) {
RedisTemplate<String, Object> redisTemplate = new RedisTemplate<String, Object>();
redisTemplate.setConnectionFactory(connectionFactory);
StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();
redisTemplate.setKeySerializer(stringRedisSerializer); // key的序列化類(lèi)型
Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
ObjectMapper objectMapper = new ObjectMapper();
objectMapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
// 方法過(guò)期,改為下面代碼
// objectMapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
objectMapper.activateDefaultTyping(LaissezFaireSubTypeValidator.instance,
ObjectMapper.DefaultTyping.NON_FINAL, JsonTypeInfo.As.PROPERTY);
jackson2JsonRedisSerializer.setObjectMapper(objectMapper);
jackson2JsonRedisSerializer.setObjectMapper(objectMapper);
redisTemplate.setValueSerializer(jackson2JsonRedisSerializer); // value的序列化類(lèi)型
redisTemplate.setHashKeySerializer(stringRedisSerializer);
redisTemplate.setHashValueSerializer(jackson2JsonRedisSerializer);
redisTemplate.afterPropertiesSet();
return redisTemplate;
}
}
把分布式鎖接口定義出來(lái),所謂面向接口和對(duì)象編程,代碼如有神。順帶用英文顯擺下什么叫做專(zhuān)業(yè)。
/**
* 分布式鎖
*/
public interface Lock {
/**
* Tries to acquire the lock with defined <code>leaseTime</code>.
* Waits up to defined <code>waitTime</code> if necessary until the lock became available.
* <p>
* Lock will be released automatically after defined <code>leaseTime</code> interval.
*
* @param waitTime the maximum time to acquire the lock
* @param leaseTime lease time
* @param unit time unit
* @return <code>true</code> if lock is successfully acquired,
* otherwise <code>false</code> if lock is already set.
* @throws InterruptedException - if the thread is interrupted
*/
boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException;
/**
* Acquires the lock with defined <code>leaseTime</code>.
* Waits if necessary until lock became available.
* <p>
* Lock will be released automatically after defined <code>leaseTime</code> interval.
*
* @param leaseTime the maximum time to hold the lock after it's acquisition,
* if it hasn't already been released by invoking <code>unlock</code>.
* If leaseTime is -1, hold the lock until explicitly unlocked.
* @param unit the time unit
*/
void lock(long leaseTime, TimeUnit unit);
/**
* Releases the lock.
*
* <p><b>Implementation Considerations</b>
*
* <p>A {@code Lock} implementation will usually impose
* restrictions on which thread can release a lock (typically only the
* holder of the lock can release it) and may throw
* an (unchecked) exception if the restriction is violated.
* Any restrictions and the exception
* type must be documented by that {@code Lock} implementation.
*/
void unlock();
}
青銅分布式鎖實(shí)戰(zhàn)
DistributedLock 實(shí)現(xiàn) Lock 接口,構(gòu)造方法實(shí)現(xiàn) resourceName 和 StringRedisTemplate 的屬性設(shè)置??蛻?hù)端唯一標(biāo)識(shí)使用uuid:threadId 組成。
DistributedLock
public class DistributedLock implements Lock {
/**
* 標(biāo)識(shí) id
*/
private final String id = UUID.randomUUID().toString();
/**
* 資源名稱(chēng)
*/
private final String resourceName;
private final List<String> keys = new ArrayList<>(1);
/**
* redis 客戶(hù)端
*/
private final StringRedisTemplate redisTemplate;
public DistributedLock(String resourceName, StringRedisTemplate redisTemplate) {
this.resourceName = resourceName;
this.redisTemplate = redisTemplate;
keys.add(resourceName);
}
private String getRequestId(long threadId) {
return id + ":" + threadId;
}
}
加鎖 tryLock、lock
tryLock 以阻塞等待 waitTime 時(shí)間的方式來(lái)嘗試獲取鎖。獲取成功則返回 true,反之 false。tryAcquire 方法相當(dāng)于執(zhí)行了 Redis 的SET resourceName uuid:threadID NX PX {leaseTime} 指令。
與 tryLock不同的是, lock 一直嘗試自旋阻塞等待獲取分布式鎖,直到獲取成功為止。而 tryLock 只會(huì)阻塞等待 waitTime 時(shí)間。
此外,為了讓程序更加健壯,碼哥實(shí)現(xiàn)了阻塞等待獲取分布式鎖,讓你用的更加開(kāi)心,面試不慌加薪不難。如果你不需要自旋阻塞等待獲取鎖,那把 while 代碼塊刪除即可。
@Override
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
long time = unit.toMillis(waitTime);
long current = System.currentTimeMillis();
long threadId = Thread.currentThread().getId();
// 獲取鎖
Boolean isAcquire = tryAcquire(leaseTime, unit, threadId);
// lock acquired
if (Boolean.TRUE.equals(isAcquire)) {
return true;
}
time -= System.currentTimeMillis() - current;
// 等待時(shí)間用完,獲取鎖失敗
if (time <= 0) {
return false;
}
// 自旋獲取鎖
while (true) {
long currentTime = System.currentTimeMillis();
isAcquire = tryAcquire(leaseTime, unit, threadId);
// lock acquired
if (Boolean.TRUE.equals(isAcquire)) {
return true;
}
time -= System.currentTimeMillis() - currentTime;
if (time <= 0) {
return false;
}
}
}
@Override
public void lock(long leaseTime, TimeUnit unit) {
long threadId = Thread.currentThread().getId();
Boolean acquired;
do {
acquired = tryAcquire(leaseTime, unit, threadId);
} while (Boolean.TRUE.equals(acquired));
}
private Boolean tryAcquire(long leaseTime, TimeUnit unit, long threadId) {
return redisTemplate.opsForValue().setIfAbsent(resourceName, getRequestId(threadId), leaseTime, unit);
}
解鎖 unlock
解鎖的邏輯是通過(guò)執(zhí)行 lua 腳本實(shí)現(xiàn)。
@Override
public void unlock() {
long threadId = Thread.currentThread().getId();
// 執(zhí)行 lua 腳本
DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>(LuaScript.unlockScript(), Long.class);
Long opStatus = redisTemplate.execute(redisScript, keys, getRequestId(threadId));
if (opStatus == null) {
throw new IllegalMonitorStateException("attempt to unlock lock, not locked by current thread by node id: "
+ id + " thread-id: " + threadId);
}
}
LuaScript
其實(shí)這個(gè)腳本就是在講解青銅板分布式鎖原理的那段代碼,具體邏輯已經(jīng)解釋過(guò),這里就不再重復(fù)分析。
public class LuaScript {
private LuaScript() {
}
/**
* 分布式鎖解鎖腳本
*
* @return 當(dāng)且僅當(dāng)返回 `1`才表示加鎖成功.
*/
public static String unlockScript() {
return "if (redis.call('exists', KEYS[1]) == 0) then " +
"return nil;" +
"end; "+
"if redis.call('get',KEYS[1]) == ARGV[1] then" +
" return redis.call('del',KEYS[1]);" +
"else" +
" return 0;" +
"end;";
}
}
RedisLockClient
最后,還需要提供一個(gè)客戶(hù)端給方便使用。
@Component
public class RedisLockClient {
@Autowired
private StringRedisTemplate redisTemplate;
public Lock getLock(String name) {
return new DistributedLock(name, redisTemplate);
}
}
單元測(cè)試來(lái)一個(gè)。
@Slf4j
@SpringBootTest(classes = RedisApplication.class)
public class RedisLockTest {
@Autowired
private RedisLockClient redisLockClient;
@Test
public void testLockSuccess() throws InterruptedException {
Lock lock = redisLockClient.getLock("order:pay");
try {
boolean isLock = lock.tryLock(10, 30, TimeUnit.SECONDS);
if (!isLock) {
log.warn("加鎖失敗");
return;
}
TimeUnit.SECONDS.sleep(3);
log.info("業(yè)務(wù)邏輯執(zhí)行完成");
} finally {
lock.unlock();
}
}
}
有兩個(gè)點(diǎn)需要注意。
- 釋放鎖的代碼一定要放在 finally{} 塊中。否則一旦執(zhí)行業(yè)務(wù)邏輯過(guò)程中拋出異常,程序就無(wú)法執(zhí)行釋放鎖的流程。只能干等著鎖超時(shí)釋放。
- 加鎖的代碼應(yīng)該寫(xiě)在 try {} 代碼中,放在 try 外面的話(huà),如果執(zhí)行加鎖異常(客戶(hù)端網(wǎng)絡(luò)連接超時(shí)),但是實(shí)際指令已經(jīng)發(fā)送到服務(wù)端并執(zhí)行,就會(huì)導(dǎo)致沒(méi)有機(jī)會(huì)執(zhí)行解鎖的代碼。
小白:“碼哥,這個(gè)方案你管它叫青銅級(jí)別而已,這么說(shuō)還有王者、超神版?我們公司還用錯(cuò)誤版分布式鎖,難怪有時(shí)候出現(xiàn)重復(fù)訂單,是我膚淺了?!?/p>
趕緊將這個(gè)方案替換原來(lái)的錯(cuò)誤或者殘血版的 Redis 分布式鎖吧。