Redis分布式鎖的正確實(shí)現(xiàn)方式是什么

本篇文章為大家展示了Redis分布式鎖的正確實(shí)現(xiàn)方式是什么，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

之前我們使用的定時(shí)任務(wù)都是只部署在了單臺機(jī)器上，為了解決單點(diǎn)的問題，為了保證一個(gè)任務(wù)，只被一臺機(jī)器執(zhí)行，就需要考慮鎖的問題，于是就花時(shí)間研究了這個(gè)問題。到底怎樣實(shí)現(xiàn)一個(gè)分布式鎖呢？

閱讀這篇文章你可以了解到：

• 單機(jī)版的實(shí)現(xiàn)

• 分布式環(huán)境下RedLock實(shí)現(xiàn)

鎖的本質(zhì)就是互斥，保證任何時(shí)候能有一個(gè)客戶端持有同一個(gè)鎖，如果考慮使用redis來實(shí)現(xiàn)一個(gè)分布式鎖，最簡單的方案就是在實(shí)例里面創(chuàng)建一個(gè)鍵值，釋放鎖的時(shí)候，將鍵值刪除。但是一個(gè)可靠完善的分布式鎖需要考慮的細(xì)節(jié)比較多，我們就來看看如何寫一個(gè)正確的分布式鎖。

單機(jī)版分布式鎖 SETNX

所以我們直接基于 redis 的 setNX (SET if Not eXists)命令，實(shí)現(xiàn)一個(gè)簡單的鎖。直接上偽碼

鎖的獲?。?/p>

    SET resource_name my_random_value NX PX 30000

鎖的釋放：

    if redis.call("get",KEYS[1]) == ARGV[1] then
        return redis.call("del",KEYS[1])
    else
        return 0
    end

幾個(gè)細(xì)節(jié)需要注意：

• 首先在獲取鎖的時(shí)候我們需要設(shè)置設(shè)置超時(shí)時(shí)間。設(shè)置超時(shí)時(shí)間是為了，防止客戶端崩潰，或者網(wǎng)絡(luò)出現(xiàn)問題以后鎖一直被持有。真?zhèn)€系統(tǒng)就死鎖了。

• 使用 setNX 命令，保證查詢和寫入兩個(gè)步驟是原子的

• 在鎖釋放的時(shí)候我們判斷了KEYS[1]) == ARGV[1]，在這里 KEYS[1]是從redis里面取出來的value，ARGV[1]是上文生成的my_random_value。之所以進(jìn)行以上的判斷，是為了保證鎖被鎖的持有者釋放。我們假設(shè)不進(jìn)行這一步校驗(yàn)：

  造成這個(gè)問題的關(guān)鍵，在于客戶端B持有的鎖，被客戶端A釋放了。

1. 客戶端A獲取鎖，后發(fā)線程掛起了。時(shí)間大于鎖的過期時(shí)間。

2. 鎖過期后，客戶端B獲取鎖。

3. 客戶端A恢復(fù)以后，處理完相關(guān)事件，向redis發(fā)起 del命令。鎖被釋放

4. 客戶端C獲取鎖。這個(gè)時(shí)候一個(gè)系統(tǒng)中同時(shí)兩個(gè)客戶端持有鎖。

• 鎖的釋放必須使用lua腳本，保證操作的原子性。鎖的釋放包含了get，判斷，del三個(gè)步驟。如果不能保證三個(gè)步驟的原子性，分布式鎖就會有并發(fā)問題。

注意了以上細(xì)節(jié)，一個(gè)單redis節(jié)點(diǎn)的分布式鎖就達(dá)成了。

在這個(gè)分布式鎖中還是存在一個(gè)單點(diǎn)的redis。也許你會說，Redis是 master-slave的架構(gòu)，發(fā)生故障的時(shí)候切換到slave就好，但是Redis的復(fù)制是異步的。

• 如果在客戶端A在master上拿到了鎖。

• 在master將數(shù)據(jù)同步到slave上之前，master宕機(jī)。

• 客戶端B就從slave上又一次拿到了鎖。

這樣由于Master的宕機(jī)，造成了同時(shí)多人持有鎖。如果你的系統(tǒng)可用接受短時(shí)時(shí)間內(nèi)，有多人持有鎖。這個(gè)簡單的方案就能解決問題。

但是如果解決這個(gè)問題。Redis的官方提供了一個(gè)Redlock的解決方案。

RedLock 的實(shí)現(xiàn)

為了解決，Redis單點(diǎn)的問題。Redis的作者提出了RedLock的解決方案。方案非常的巧妙和簡潔。
RedLock的核心思想就是，同時(shí)使用多個(gè)Redis Master來冗余，且這些節(jié)點(diǎn)都是完全的獨(dú)立的，也不需要對這些節(jié)點(diǎn)之間的數(shù)據(jù)進(jìn)行同步。

假設(shè)我們有N個(gè)Redis節(jié)點(diǎn)，N應(yīng)該是一個(gè)大于2的奇數(shù)。RedLock的實(shí)現(xiàn)步驟:

1. 取得當(dāng)前時(shí)間

2. 使用上文提到的方法依次獲取N個(gè)節(jié)點(diǎn)的Redis鎖。

3. 如果獲取到的鎖的數(shù)量大于 （N/2+1）個(gè),且獲取的時(shí)間小于鎖的有效時(shí)間(lock validity time)就認(rèn)為獲取到了一個(gè)有效的鎖。鎖自動釋放時(shí)間就是最初的鎖釋放時(shí)間減去之前獲取鎖所消耗的時(shí)間。

4. 如果獲取鎖的數(shù)量小于 （N/2+1），或者在鎖的有效時(shí)間(lock validity time)內(nèi)沒有獲取到足夠的說，就認(rèn)為獲取鎖失敗。這個(gè)時(shí)候需要向所有節(jié)點(diǎn)發(fā)送釋放鎖的消息。

對于釋放鎖的實(shí)現(xiàn)就很簡單了。想所有的Redis節(jié)點(diǎn)發(fā)起釋放的操作，無論之前是否獲取鎖成功。

同時(shí)需要注意幾個(gè)細(xì)節(jié)：

• 重試獲取鎖的間隔時(shí)間應(yīng)當(dāng)是一個(gè)隨機(jī)范圍而非一個(gè)固定時(shí)間。這樣可以防止，多客戶端同時(shí)一起向Redis集群發(fā)送獲取鎖的操作，避免同時(shí)競爭。同時(shí)獲取相同數(shù)量鎖的情況。（雖然概率很低）

• 如果某master節(jié)點(diǎn)故障之后，回復(fù)的時(shí)間間隔應(yīng)當(dāng)大于鎖的有效時(shí)間。

  所以如果恢復(fù)的時(shí)間將大于鎖的有效時(shí)間，就可以避免以上情況發(fā)生。同時(shí)如果性能要求不高，甚至可以開啟Redis的持久化選項(xiàng)。

1. 假設(shè)有A，B，C三個(gè)Redis節(jié)點(diǎn)。

2. 客戶端foo獲取到了A、B兩個(gè)鎖。

3. 這個(gè)時(shí)候B宕機(jī)，所有內(nèi)存的數(shù)據(jù)丟失。

4. B節(jié)點(diǎn)恢復(fù)。

5. 這個(gè)時(shí)候客戶端bar重新獲取鎖，獲取到B，C兩個(gè)節(jié)點(diǎn)。

6. 此時(shí)又有兩個(gè)客戶端獲取到鎖了。

上述內(nèi)容就是Redis分布式鎖的正確實(shí)現(xiàn)方式是什么，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。