基于 Redis 如何實現(xiàn)一個分布式鎖？

作者： 張張 2021-11-01 12:25:56
存儲
存儲軟件
分布式
Redis 與分布式鎖相對應(yīng)的是「單機鎖」，我們在寫多線程程序時，避免同時操作一個共享變量產(chǎn)生數(shù)據(jù)問題，通常會使用一把鎖來「互斥」，以保證共享變量的正確性，其使用范圍是在「同一個進程」中。

站在用戶的角度思考問題，與客戶深入溝通，找到陽谷網(wǎng)站設(shè)計與陽谷網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：網(wǎng)站設(shè)計、網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋陽谷地區(qū)。

一、為什么需要分布式鎖?

在開始講分布式鎖之前，有必要簡單介紹一下，為什么需要分布式鎖?

與分布式鎖相對應(yīng)的是「單機鎖」，我們在寫多線程程序時，避免同時操作一個共享變量產(chǎn)生數(shù)據(jù)問題，通常會使用一把鎖來「互斥」，以保證共享變量的正確性，其使用范圍是在「同一個進程」中。

如果換做是多個進程，需要同時操作一個共享資源，如何互斥呢?

例如，現(xiàn)在的業(yè)務(wù)應(yīng)用通常都是微服務(wù)架構(gòu)，這也意味著一個應(yīng)用會部署多個進程，那這多個進程如果需要修改 MySQL 中的同一行記錄時，為了避免操作亂序?qū)е聰?shù)據(jù)錯誤，此時，我們就需要引入「分布式鎖」來解決這個問題了。

想要實現(xiàn)分布式鎖，必須借助一個外部系統(tǒng)，所有進程都去這個系統(tǒng)上申請「加鎖」。

而這個外部系統(tǒng)，必須要實現(xiàn)「互斥」的能力，即兩個請求同時進來，只會給一個進程返回成功，另一個返回失敗(或等待)。

這個外部系統(tǒng)，可以是 MySQL，也可以是 Redis 或 Zookeeper。但為了追求更好的性能，我們通常會選擇使用 Redis 或 Zookeeper 來做。

下面我就以 Redis 為主線，由淺入深，帶你深度剖析一下，分布式鎖的各種「安全性」問題，幫你徹底理解分布式鎖。

二、分布式鎖怎么實現(xiàn)?

我們從最簡單的開始講起。

想要實現(xiàn)分布式鎖，必須要求 Redis 有「互斥」的能力，我們可以使用 SETNX 命令，這個命令表示SET if Not eXists，即如果 key 不存在，才會設(shè)置它的值，否則什么也不做。

兩個客戶端進程可以執(zhí)行這個命令，達到互斥，就可以實現(xiàn)一個分布式鎖。

客戶端 1 申請加鎖，加鎖成功：

  
 
 
 

   
  
  
  
127.0.0.1:6379> SETNX lock 1 
   
  
  
  
(integer) 1     // 客戶端1，加鎖成功 
  
 
 
 

客戶端 2 申請加鎖，因為后到達，加鎖失?。?/p>

  
 
 
 

   
  
  
  
127.0.0.1:6379> SETNX lock 1 
   
  
  
  
(integer) 0     // 客戶端2，加鎖失敗 
  
 
 
 

此時，加鎖成功的客戶端，就可以去操作「共享資源」，例如，修改 MySQL 的某一行數(shù)據(jù)，或者調(diào)用一個 API 請求。

操作完成后，還要及時釋放鎖，給后來者讓出操作共享資源的機會。如何釋放鎖呢?

也很簡單，直接使用 DEL 命令刪除這個 key 即可：

  
 
 
 

   
  
  
  
127.0.0.1:6379> DEL lock // 釋放鎖 
   
  
  
  
(integer) 1 
  
 
 
 

這個邏輯非常簡單，整體的路程就是這樣：

但是，它存在一個很大的問題，當客戶端 1 拿到鎖后，如果發(fā)生下面的場景，就會造成「死鎖」：

程序處理業(yè)務(wù)邏輯異常，沒及時釋放鎖

進程掛了，沒機會釋放鎖

這時，這個客戶端就會一直占用這個鎖，而其它客戶端就「永遠」拿不到這把鎖了。

怎么解決這個問題呢?

三、如何避免死鎖?

我們很容易想到的方案是，在申請鎖時，給這把鎖設(shè)置一個「租期」。

在 Redis 中實現(xiàn)時，就是給這個 key 設(shè)置一個「過期時間」。這里我們假設(shè)，操作共享資源的時間不會超過 10s，那么在加鎖時，給這個 key 設(shè)置 10s 過期即可：

  
 
 
 

   
  
  
  
127.0.0.1:6379> SETNX lock 1    // 加鎖 
   
  
  
  
(integer) 1 
   
  
  
  
127.0.0.1:6379> EXPIRE lock 10  // 10s后自動過期 
   
  
  
  
(integer) 1 
  
 
 
 

這樣一來，無論客戶端是否異常，這個鎖都可以在 10s 后被「自動釋放」，其它客戶端依舊可以拿到鎖。

疑問臉，但這樣真的沒問題嗎?

還是有問題。

現(xiàn)在的操作，加鎖、設(shè)置過期是 2 條命令，有沒有可能只執(zhí)行了第一條，第二條卻「來不及」執(zhí)行的情況發(fā)生呢?例如：

• SETNX 執(zhí)行成功，執(zhí)行 EXPIRE 時由于網(wǎng)絡(luò)問題，執(zhí)行失敗
• SETNX 執(zhí)行成功，Redis 異常宕機，EXPIRE 沒有機會執(zhí)行
• SETNX 執(zhí)行成功，客戶端異常崩潰，EXPIRE 也沒有機會執(zhí)行

總之，這兩條命令不能保證是原子操作(一起成功)，就有潛在的風險導(dǎo)致過期時間設(shè)置失敗，依舊發(fā)生「死鎖」問題。

那怎么辦呢?

在 Redis 2.6.12 版本之前，我們需要想盡辦法，保證 SETNX 和 EXPIRE 原子性執(zhí)行，還要考慮各種異常情況如何處理。

但在 Redis 2.6.12 之后，Redis 擴展了 SET 命令的參數(shù)，用這一條命令就可以了：

  
 
 
 

   
  
  
  
// 一條命令保證原子性執(zhí)行 
   
  
  
  
127.0.0.1:6379> SET lock 1 EX 10 NX 
   
  
  
  
OK 
  
 
 
 

這樣就解決了死鎖問題，也比較簡單。

當前題目：基于Redis如何實現(xiàn)一個分布式鎖？
本文網(wǎng)址：http://m.5511xx.com/article/ccddcpe.html