Redis命令SETNX的使用（包含Java分佈式鎖實現）

Redis命令SETNX的使用（包含Java分佈式鎖實現）

可以參考Redis官網對SETNX命令的介紹：

https://redis.io/commands/setnx

SETNX命令簡介

命令格式

SETNX key value

將 key 的值設爲 value，當且僅當 key 不存在。 
若給定的 key 已經存在，則 SETNX 不做任何動作。 
SETNX 是SET if Not eXists的簡寫。

返回值
返回整數，具體爲 

 - 1，當 key 的值被設置 
- 0，當 key 的值沒被設置

例子

redis> SETNX mykey “hello” 
(integer) 1 
redis> SETNX mykey “hello” 
(integer) 0 
redis> GET mykey 
“hello” 
redis>

使用SETNX實現分佈式鎖
多個進程執行以下Redis命令：

SETNX lock.foo <current Unix time + lock timeout + 1>

如果 SETNX 返回1，說明該進程獲得鎖，SETNX將鍵 lock.foo 的值設置爲鎖的超時時間（當前時間 + 鎖的有效時間）。 
如果 SETNX 返回0，說明其他進程已經獲得了鎖，進程不能進入臨界區。進程可以在一個循環中不斷地嘗試 SETNX 操作，以獲得鎖。

解決死鎖
考慮一種情況，如果進程獲得鎖後，斷開了與 Redis 的連接（可能是進程掛掉，或者網絡中斷），如果沒有有效的釋放鎖的機制，那麼其他進程都會處於一直等待的狀態，即出現“死鎖”。

上面在使用 SETNX 獲得鎖時，我們將鍵 lock.foo 的值設置爲鎖的有效時間，進程獲得鎖後，其他進程還會不斷的檢測鎖是否已超時，如果超時，那麼等待的進程也將有機會獲得鎖。

然而，鎖超時時，我們不能簡單地使用 DEL 命令刪除鍵 lock.foo 以釋放鎖。考慮以下情況，進程P1已經首先獲得了鎖 lock.foo，然後進程P1掛掉了。進程P2，P3正在不斷地檢測鎖是否已釋放或者已超時，執行流程如下：

• P2和P3進程讀取鍵 lock.foo 的值，檢測鎖是否已超時（通過比較當前時間和鍵 lock.foo 的值來判斷是否超時）
• P2和P3進程發現鎖 lock.foo 已超時
• P2執行 DEL lock.foo命令
• P2執行 SETNX lock.foo命令，並返回1，即P2獲得鎖
• P3執行 DEL lock.foo命令將P2剛剛設置的鍵 lock.foo 刪除（這步是由於P3剛纔已檢測到鎖已超時）
• P3執行 SETNX lock.foo命令，並返回1，即P3獲得鎖
• P2和P3同時獲得了鎖

從上面的情況可以得知，在檢測到鎖超時後，進程不能直接簡單地執行 DEL 刪除鍵的操作以獲得鎖。

爲了解決上述算法可能出現的多個進程同時獲得鎖的問題，我們再來看以下的算法。 
我們同樣假設進程P1已經首先獲得了鎖 lock.foo，然後進程P1掛掉了。接下來的情況：

• 進程P4執行 SETNX lock.foo 以嘗試獲取鎖
• 由於進程P1已獲得了鎖，所以P4執行 SETNX lock.foo 返回0，即獲取鎖失敗
• P4執行 GET lock.foo 來檢測鎖是否已超時，如果沒超時，則等待一段時間，再次檢測
• 如果P4檢測到鎖已超時，即當前的時間大於鍵 lock.foo 的值，P4會執行以下操作 
• GETSET lock.foo <current Unix timestamp + lock timeout + 1>
• 由於 GETSET 操作在設置鍵的值的同時，還會返回鍵的舊值，通過比較鍵 lock.foo 的舊值是否小於當前時間，可以判斷進程是否已獲得鎖
• 假如另一個進程P5也檢測到鎖已超時，並在P4之前執行了 GETSET 操作，那麼P4的 GETSET 操作返回的是一個大於當前時間的時間戳，這樣P4就不會獲得鎖而繼續等待。注意到，即使P4接下來將鍵 lock.foo 的值設置了比P5設置的更大的值也沒影響。

另外，值得注意的是，在進程釋放鎖，即執行 DEL lock.foo 操作前，需要先判斷鎖是否已超時。如果鎖已超時，那麼鎖可能已由其他進程獲得，這時直接執行 DEL lock.foo 操作會導致把其他進程已獲得的鎖釋放掉。

 

使用SETNX命令結合Java應用實現分佈式鎖

項目使用SETNX實現分佈式鎖原因：

由於線上所有的微服務都是採用兩個服務節點來進行部署的，正常情況下不會出現兩個服務節點同時執行同一個方法，即同一段業務邏輯，遇到這樣一種情況，在部署的微服務中存在定時任務，也就是在將來的某個時間點會觸發這個任務自動執行，那麼這時候兩個服務節點在這個時間點都會開啓一個線程去執行相同的代碼邏輯，顯然這是違反業務邏輯的，即重複執行了一樣的邏輯，因此在這種情況下就需要加入分佈式鎖來解決這樣的定時任務場景問題。

其中一個定時任務代碼：

package com.huajin.usercenter.task;

import java.util.Calendar;
import java.util.Date;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

import com.huajin.common.util.DateUtil;
import com.huajin.usercenter.enums.CertStatus;
import com.huajin.usercenter.po.CertInfoPo;
import com.huajin.usercenter.service.seal.CertService;

import lombok.extern.slf4j.Slf4j;

@Component
@Slf4j
public class CertTask {
	
	@Autowired
	private CertService certService;
	
	@Scheduled(cron = "0 0 0 * * ?")
    public void updateAuthCode() {
		Map<String, Object> map = new HashMap<>();
		map.put("status", CertStatus.NotDownload.getValue());
		map.put("updateTimeEnd", DateUtil.add(new Date(), Calendar.DAY_OF_YEAR, -10));
		List<CertInfoPo> list = certService.select(map);
		for(CertInfoPo po : list) {
			try {
				certService.updateAuthCode(po.getSn());
			} catch (Exception e) {
				log.error("", e);
			}
		}
    }
	
}

介紹了使用分佈式鎖的場景，那麼怎麼使用Redis提供的SETNX命令實現分佈式鎖呢？

由於項目中不止存在一個定時任務，且使用分佈式鎖不屬於主業務邏輯部分，因此採用了AOP面向切面編程，項目中存在的定時任務均在task包下，還有一個特點就是所有的定時任務方法都有Spring提供的定時任務註解@Scheduled

，考慮到這裏我們便知道了切點就是兩者的結合，爲了保險起見，採用&&符號連接這兩個條件，接下來就是考慮使用何種通知方式，考慮到線程執行的快慢，定時任務方法時刻都在兩個服務節點開啓的定時任務線程爭奪中，因此在這裏使用@Around註解，即環繞通知實現。

在這裏特別強調一下@Around環繞通知去其它幾個通知的區別，@Around環繞通知接受的是ProceedingJoinPoint接口的實現類的一個實例，該ProceedingJoinPoint接口繼承自JoinPoint接口，ProceedingJoinPoint接口比JoinPoint接口多暴露了兩個方法，如下所示：

接下來便是使用RedisTemplate提供的API來操作Redis命令SETNX實現分佈式鎖，

package com.huajin.usercenter.task;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Component;

import lombok.extern.slf4j.Slf4j;

@Aspect
@Component
@Slf4j
public class TaskAspect {
	
	@Autowired
	private RedisTemplate<Object, Object> redisTemplate;
	
	@Around("execution(* com.huajin.usercenter.task..*.*(..)) && @annotation(org.springframework.scheduling.annotation.Scheduled)")
	public Object task(ProceedingJoinPoint point) {
		String methodName = point.getTarget().getClass().getName() + "." + point.getSignature().getName();
		Boolean result = redisTemplate.opsForValue().setIfAbsent(methodName, methodName);
		if(result != null && result) {
			try {
				return point.proceed();
			} catch (Throwable e) {
				log.error("", e);
			} finally {
				redisTemplate.delete(methodName);
			}
		}
		return null;
	}
	
}

以上兩個服務節點開啓的定時任務線程中的某個線程在key不存在的情況下則相當於與獲取到了鎖，待目標方法執行完畢後或者拋出異常都可以刪除這個key，即也就是釋放鎖，達到了分佈式鎖的目的。

 

參考：

https://blog.csdn.net/lihao21/article/details/49104695