Redis實現分布式鎖的方法示例

更新時間：2017年10月24日 10:08:52 作者：犀利豆

本篇文章主要介紹了Redis實現分布式鎖的方法示例，小編覺得挺不錯的，現在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧

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

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

單機版分布式鎖 SETNX

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

鎖的獲?。?/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

幾個細節(jié)需要注意：

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

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

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

造成這個問題的關鍵，在于客戶端B持有的鎖，被客戶端A釋放了。

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

注意了以上細節(jié)，一個單redis節(jié)點的分布式鎖就達成了。

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

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

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

RedLock 的實現

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

假設我們有N個Redis節(jié)點，N應該是一個大于2的奇數。RedLock的實現步驟:

取得當前時間
使用上文提到的方法依次獲取N個節(jié)點的Redis鎖。
如果獲取到的鎖的數量大于（N/2+1）個,且獲取的時間小于鎖的有效時間(lock validity time)就認為獲取到了一個有效的鎖。鎖自動釋放時間就是最初的鎖釋放時間減去之前獲取鎖所消耗的時間。
如果獲取鎖的數量小于（N/2+1），或者在鎖的有效時間(lock validity time)內沒有獲取到足夠的說，就認為獲取鎖失敗。這個時候需要向所有節(jié)點發(fā)送釋放鎖的消息。

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

同時需要注意幾個細節(jié)：

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

如果某master節(jié)點故障之后，回復的時間間隔應當大于鎖的有效時間。