Redis實現(xiàn)分布式鎖的五種方法詳解
在單體應(yīng)用中，如果我們對共享數(shù)據(jù)不進行加鎖操作，會出現(xiàn)數(shù)據(jù)一致性問題，我們的解決辦法通常是加鎖。
在分布式架構(gòu)中，我們同樣會遇到數(shù)據(jù)共享操作問題，本文章使用Redis來解決分布式架構(gòu)中的數(shù)據(jù)一致性問題。
1. 單機數(shù)據(jù)一致性
單機數(shù)據(jù)一致性架構(gòu)如下圖所示：多個可客戶訪問同一個服務(wù)器，連接同一個數(shù)據(jù)庫。
場景描述：客戶端模擬購買商品過程，在Redis中設(shè)定庫存總數(shù)剩100個，多個客戶端同時并發(fā)購買。
@RestController
public class IndexController1 {
@Autowired
StringRedisTemplate template;
@RequestMapping("/buy1")
public String index(){
// Redis中存有g(shù)oods:001號商品，數(shù)量為100
String result = template.opsForValue().get("goods:001");
// 獲取到剩余商品數(shù)
int total = result == null ? 0 : Integer.parseInt(result);
if( total > 0 ){
// 剩余商品數(shù)大于0 ，則進行扣減
int realTotal = total -1;
// 將商品數(shù)回寫數(shù)據(jù)庫
template.opsForValue().set("goods:001",String.valueOf(realTotal));
System.out.println("購買商品成功，庫存還剩："+realTotal +"件， 服務(wù)端口為8001");
return "購買商品成功，庫存還剩："+realTotal +"件， 服務(wù)端口為8001";
}else{
System.out.println("購買商品失敗，服務(wù)端口為8001");
}
return "購買商品失敗，服務(wù)端口為8001";
}
}
使用Jmeter模擬高并發(fā)場景，測試結(jié)果如下：
測試結(jié)果出現(xiàn)多個用戶購買同一商品，發(fā)生了數(shù)據(jù)不一致問題！
解決辦法：單體應(yīng)用的情況下，對并發(fā)的操作進行加鎖操作，保證對數(shù)據(jù)的操作具有原子性
synchronizedReentrantLock
@RestController
public class IndexController2 {
// 使用ReentrantLock鎖解決單體應(yīng)用的并發(fā)問題
Lock lock = new ReentrantLock();
@Autowired
StringRedisTemplate template;
@RequestMapping("/buy2")
public String index() {
lock.lock();
try {
String result = template.opsForValue().get("goods:001");
int total = result == null ? 0 : Integer.parseInt(result);
if (total > 0) {
int realTotal = total - 1;
template.opsForValue().set("goods:001", String.valueOf(realTotal));
System.out.println("購買商品成功，庫存還剩：" + realTotal + "件， 服務(wù)端口為8001");
return "購買商品成功，庫存還剩：" + realTotal + "件， 服務(wù)端口為8001";
} else {
System.out.println("購買商品失敗，服務(wù)端口為8001");
}
} catch (Exception e) {
lock.unlock();
} finally {
lock.unlock();
}
return "購買商品失敗，服務(wù)端口為8001";
}
}
2. 分布式數(shù)據(jù)一致性
上面解決了單體應(yīng)用的數(shù)據(jù)一致性問題，但如果是分布式架構(gòu)部署呢，架構(gòu)如下：
提供兩個服務(wù)，端口分別為8001、8002，連接同一個Redis服務(wù)，在服務(wù)前面有一臺Nginx作為負載均衡
兩臺服務(wù)代碼相同，只是端口不同
將8001、8002兩個服務(wù)啟動，每個服務(wù)依然用ReentrantLock加鎖，用Jmeter做并發(fā)測試，發(fā)現(xiàn)會出現(xiàn)數(shù)據(jù)一致性問題！
3. Redis實現(xiàn)分布式鎖
3.1 方式一
取消單機鎖，下面使用redis的set命令來實現(xiàn)分布式加鎖
SET KEY VALUE [EX seconds] [PX milliseconds] [NX|XX]
- EX seconds 設(shè)置指定的到期時間(以秒為單位)
- PX milliseconds 設(shè)置指定的到期時間(以毫秒為單位)
- NX 僅在鍵不存在時設(shè)置鍵
- XX 只有在鍵已存在時才設(shè)置
@RestController
public class IndexController4 {
// Redis分布式鎖的key
public static final String REDIS_LOCK = "good_lock";
@Autowired
StringRedisTemplate template;
@RequestMapping("/buy4")
public String index(){
// 每個人進來先要進行加鎖，key值為"good_lock"，value隨機生成
String value = UUID.randomUUID().toString().replace("-","");
try{
// 加鎖
Boolean flag = template.opsForValue().setIfAbsent(REDIS_LOCK, value);
// 加鎖失敗
if(!flag){
return "搶鎖失??！";
}
System.out.println( value+ " 搶鎖成功");
String result = template.opsForValue().get("goods:001");
int total = result == null ? 0 : Integer.parseInt(result);
if (total > 0) {
int realTotal = total - 1;
template.opsForValue().set("goods:001", String.valueOf(realTotal));
// 如果在搶到所之后，刪除鎖之前，發(fā)生了異常，鎖就無法被釋放，
// 釋放鎖操作不能在此操作，要在finally處理
// template.delete(REDIS_LOCK);
System.out.println("購買商品成功，庫存還剩：" + realTotal + "件， 服務(wù)端口為8001");
return "購買商品成功，庫存還剩：" + realTotal + "件， 服務(wù)端口為8001";
} else {
System.out.println("購買商品失敗，服務(wù)端口為8001");
}
return "購買商品失敗，服務(wù)端口為8001";
}finally {
// 釋放鎖
template.delete(REDIS_LOCK);
}
}
}
上面的代碼，可以解決分布式架構(gòu)中數(shù)據(jù)一致性問題。但再仔細想想，還是會有問題，下面進行改進。
3.2 方式二（改進方式一）
在上面的代碼中，如果程序在運行期間，部署了微服務(wù)jar包的機器突然掛了，代碼層面根本就沒有走到finally代碼塊，也就是說在宕機前，鎖并沒有被刪除掉，這樣的話，就沒辦法保證解鎖
所以，這里需要對這個key加一個過期時間，Redis中設(shè)置過期時間有兩種方法：
template.expire(REDIS_LOCK,10, TimeUnit.SECONDS)template.opsForValue().setIfAbsent(REDIS_LOCK, value,10L,TimeUnit.SECONDS)
第一種方法需要單獨的一行代碼，且并沒有與加鎖放在同一步操作，所以不具備原子性，也會出問題
第二種方法在加鎖的同時就進行了設(shè)置過期時間，所有沒有問題，這里采用這種方式
調(diào)整下代碼，在加鎖的同時，設(shè)置過期時間：
// 為key加一個過期時間，其余代碼不變 Boolean flag = template.opsForValue().setIfAbsent(REDIS_LOCK,value,10L,TimeUnit.SECONDS);
這種方式解決了因服務(wù)突然宕機而無法釋放鎖的問題。但再仔細想想，還是會有問題，下面進行改進。
3.3 方式三（改進方式二）
方式二設(shè)置了key的過期時間，解決了key無法刪除的問題，但問題又來了
上面設(shè)置了key的過期時間為10秒，如果業(yè)務(wù)邏輯比較復(fù)雜，需要調(diào)用其他微服務(wù)，處理時間需要15秒（模擬場
景，別較真），而當(dāng)10秒鐘過去之后，這個key就過期了，其他請求就又可以設(shè)置這個key，此時如果耗時15秒
的請求處理完了，回來繼續(xù)執(zhí)行程序，就會把別人設(shè)置的key給刪除了，這是個很嚴重的問題！
所以，誰上的鎖，誰才能刪除
@RestController
public class IndexController6 {
public static final String REDIS_LOCK = "good_lock";
@Autowired
StringRedisTemplate template;
@RequestMapping("/buy6")
public String index(){
// 每個人進來先要進行加鎖，key值為"good_lock"
String value = UUID.randomUUID().toString().replace("-","");
try{
// 為key加一個過期時間
Boolean flag = template.opsForValue().setIfAbsent(REDIS_LOCK, value,10L,TimeUnit.SECONDS);
// 加鎖失敗
if(!flag){
return "搶鎖失?。?;
}
System.out.println( value+ " 搶鎖成功");
String result = template.opsForValue().get("goods:001");
int total = result == null ? 0 : Integer.parseInt(result);
if (total > 0) {
// 如果在此處需要調(diào)用其他微服務(wù)，處理時間較長。。。
int realTotal = total - 1;
template.opsForValue().set("goods:001", String.valueOf(realTotal));
System.out.println("購買商品成功，庫存還剩：" + realTotal + "件， 服務(wù)端口為8001");
return "購買商品成功，庫存還剩：" + realTotal + "件， 服務(wù)端口為8001";
} else {
System.out.println("購買商品失敗，服務(wù)端口為8001");
}
return "購買商品失敗，服務(wù)端口為8001";
}finally {
// 誰加的鎖，誰才能刪除！?。?！
if(template.opsForValue().get(REDIS_LOCK).equals(value)){
template.delete(REDIS_LOCK);
}
}
}
}
這種方式解決了因服務(wù)處理時間太長而釋放了別人鎖的問題。這樣就沒問題了嗎？
3.4 方式四（改進方式三）
在上面方式三下，規(guī)定了誰上的鎖，誰才能刪除，但finally快的判斷和del刪除操作不是原子操作，并發(fā)的時候也會出問題，并發(fā)嘛，就是要保證數(shù)據(jù)的一致性，保證數(shù)據(jù)的一致性，最好要保證對數(shù)據(jù)的操作具有原子性。
在Redis的set命令介紹中，最后推薦Lua腳本進行鎖的刪除，地址
@RestController
public class IndexController7 {
public static final String REDIS_LOCK = "good_lock";
@Autowired
StringRedisTemplate template;
@RequestMapping("/buy7")
public String index(){
// 每個人進來先要進行加鎖，key值為"good_lock"
String value = UUID.randomUUID().toString().replace("-","");
try{
// 為key加一個過期時間
Boolean flag = template.opsForValue().setIfAbsent(REDIS_LOCK, value,10L,TimeUnit.SECONDS);
// 加鎖失敗
if(!flag){
return "搶鎖失?。?;
}
System.out.println( value+ " 搶鎖成功");
String result = template.opsForValue().get("goods:001");
int total = result == null ? 0 : Integer.parseInt(result);
if (total > 0) {
// 如果在此處需要調(diào)用其他微服務(wù)，處理時間較長。。。
int realTotal = total - 1;
template.opsForValue().set("goods:001", String.valueOf(realTotal));
System.out.println("購買商品成功，庫存還剩：" + realTotal + "件， 服務(wù)端口為8001");
return "購買商品成功，庫存還剩：" + realTotal + "件， 服務(wù)端口為8001";
} else {
System.out.println("購買商品失敗，服務(wù)端口為8001");
}
return "購買商品失敗，服務(wù)端口為8001";
}finally {
// 誰加的鎖，誰才能刪除，使用Lua腳本，進行鎖的刪除
Jedis jedis = null;
try{
jedis = RedisUtils.getJedis();
String script = "if redis.call('get',KEYS[1]) == ARGV[1] " +
"then " +
"return redis.call('del',KEYS[1]) " +
"else " +
" return 0 " +
"end";
Object eval = jedis.eval(script, Collections.singletonList(REDIS_LOCK), Collections.singletonList(value));
if("1".equals(eval.toString())){
System.out.println("-----del redis lock ok....");
}else{
System.out.println("-----del redis lock error ....");
}
}catch (Exception e){
}finally {
if(null != jedis){
jedis.close();
}
}
}
}
}
3.5 方式五（改進方式四）
在方式四下，規(guī)定了誰上的鎖，誰才能刪除，并且解決了刪除操作沒有原子性問題。但還沒有考慮緩存續(xù)命，以及Redis集群部署下，異步復(fù)制造成的鎖丟失：主節(jié)點沒來得及把剛剛set進來這條數(shù)據(jù)給從節(jié)點，就掛了。所以直接上RedLock的Redisson落地實現(xiàn)。
@RestController
public class IndexController8 {
public static final String REDIS_LOCK = "good_lock";
@Autowired
StringRedisTemplate template;
@Autowired
Redisson redisson;
@RequestMapping("/buy8")
public String index(){
RLock lock = redisson.getLock(REDIS_LOCK);
lock.lock();
// 每個人進來先要進行加鎖，key值為"good_lock"
String value = UUID.randomUUID().toString().replace("-","");
try{
String result = template.opsForValue().get("goods:001");
int total = result == null ? 0 : Integer.parseInt(result);
if (total > 0) {
// 如果在此處需要調(diào)用其他微服務(wù)，處理時間較長。。。
int realTotal = total - 1;
template.opsForValue().set("goods:001", String.valueOf(realTotal));
System.out.println("購買商品成功，庫存還剩：" + realTotal + "件， 服務(wù)端口為8001");
return "購買商品成功，庫存還剩：" + realTotal + "件， 服務(wù)端口為8001";
} else {
System.out.println("購買商品失敗，服務(wù)端口為8001");
}
return "購買商品失敗，服務(wù)端口為8001";
}finally {
if(lock.isLocked() && lock.isHeldByCurrentThread()){
lock.unlock();
}
}
}
}
3.6 小結(jié)
分析問題的過程，也是解決問題的過程，也能鍛煉自己編寫代碼時思考問題的方式和角度。
以上就是Redis實現(xiàn)分布式鎖的五種方法詳解的詳細內(nèi)容，更多關(guān)于Redis分布式鎖的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
延遲是指當(dāng)前請求邏輯處理延時,而不是當(dāng)前線程或進程睡眠延遲,下面這篇文章主要給大家介紹了關(guān)于redis延遲雙刪策略的相關(guān)資料,文中通過實例代碼介紹的非常詳細,需要的朋友可以參考下2023-04-04
詳解redis數(shù)據(jù)結(jié)構(gòu)之sds
sds是Simple Dynamic String的縮寫，譯為簡單動態(tài)字符串，redis使用該結(jié)構(gòu)保存字符串，不同于c中的字符串，redis使用該結(jié)構(gòu)來更方便的進行字符串的處理,需要的朋友可以參考下2017-05-05
這篇文章主要介紹了深入理解 Redis Template及4種序列化方式，文中通過示例代碼介紹的非常詳細，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-03-03
這篇文章主要介紹了Redis swap空間的使用示例，幫助大家更好的理解和學(xué)習(xí)使用Redis數(shù)據(jù)庫，感興趣的朋友可以了解下2021-03-03
完美解決Redis在雙擊redis-server.exe出現(xiàn)閃退問題
本文主要介紹了完美解決Redis在雙擊redis-server.exe出現(xiàn)閃退問題，文中通過示例代碼介紹的非常詳細，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-01-01
高并發(fā)下Redis如何保持數(shù)據(jù)一致性(避免讀后寫)
本文主要介紹了高并發(fā)下Redis如何保持數(shù)據(jù)一致性(避免讀后寫)，文中通過示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2022-03-03
Redis是一個key-value存儲系統(tǒng)，現(xiàn)在在各種系統(tǒng)中的使用越來越多，大部分情況下是因為其高性能的特性，被當(dāng)做緩存使用，這里介紹下Redis經(jīng)常遇到的使用場景2021-06-06
redis快照模式_動力節(jié)點Java學(xué)院整理
這篇文章主要為大家詳細介紹了redis快照模式的相關(guān)資料，具有一定的參考價值，感興趣的小伙伴們可以參考一下2017-08-08
這篇文章主要為大家介紹了Redis處理高并發(fā)之布隆過濾器詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2022-12-12
這篇文章主要介紹了詳解Redis中Lua腳本的應(yīng)用和實踐，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2019-01-01