Node.js 中實踐基於 Redis 的分佈式鎖實現

時間  2019-11-29
標籤 node.js node 實踐 基於 redis 分佈式 實現 欄目 Node.js 简体版
原文   原文鏈接

在一些分佈式環境下、多線程併發編程中，若是對同一資源進行讀寫操做，避免不了的一個就是資源競爭問題，經過引入分佈式鎖這一律念，能夠解決數據一致性問題。html

做者簡介：五月君，Nodejs Developer，慕課網認證做者，熱愛技術、喜歡分享的 90 後青年，歡迎關注 Nodejs技術棧 和 Github 開源項目 www.nodejs.rednode

認識線程、進程、分佈式鎖

線程鎖：單線程編程模式下請求是順序的，一個好處是不須要考慮線程安全、資源競爭問題，所以當你進行 Node.js 編程時，也不會去考慮線程安全問題。那麼多線程編程模式下，例如 Java 你可能很熟悉一個詞 synchronized，一般也是 Java 中解決併發編程最簡單的一種方式，synchronized 能夠保證在同一時刻僅有一個線程去執行某個方法或某塊代碼。git

進程鎖：一個服務部署於一臺服務器，同時開啓多個進程，Node.js 編程中爲了利用操做系統資源，根據 CPU 的核心數能夠開啓多進程模式，這個時候若是對一個共享資源操做仍是會遇到資源競爭問題，另外每個進程都是相互獨立的，擁有本身獨立的內存空間。關於進程鎖經過 Java 中的 synchronized 也很難去解決，synchronized 僅侷限於在同一個 JVM 中有效。github

分佈式鎖：一個服務不管是單線程仍是多進程模式，當多機部署、處於分佈式環境下對同一共享資源進行操做仍是會面臨一樣的問題。此時就要去引入一個概念分佈式鎖。以下圖所示，因爲先讀數據在經過業務邏輯修改以後進行 SET 操做，這並非一個原子操做，當多個客戶端對同一資源進行先讀後寫操做就會引起併發問題，這時就要引入分佈式鎖去解決，一般也是一個很普遍的解決方案。redis

圖片描述

基於 Redis 的分佈式鎖實現思路

實現分佈式鎖的方式有不少：數據庫、Redis、Zookeeper。這裏主要介紹的是經過 Redis 來實現一個分佈式鎖，至少要保證三個特性：安全性、死鎖、容錯。算法

安全性：所謂一個蘿蔔一個坑，第一點要作的是上鎖，在任意時刻要保證僅有一個客戶端持有該鎖。數據庫

死鎖：形成死鎖多是因爲某種緣由，本該釋放的鎖沒有被釋放，所以在上鎖的時候能夠同步的設置過時時間，若是因爲客戶端本身的緣由沒有被釋放，也要保證鎖可以自動釋放。npm

容錯：容錯是在多節點的模式下須要考慮的，只要能保證 N/2+1 節點可用，客戶端就能夠成功獲取、釋放鎖。編程

Redis 單實例分佈式鎖實現

在 Redis 的單節點實例下實現一個簡單的分佈式鎖，這裏會藉助一些簡單的 Lua 腳原本實現原子性，不瞭解能夠參考以前的文章 Node.js 中實踐 Redis Lua 腳本安全

上鎖

上鎖的第一步就是先經過 setnx 命令佔坑，爲了防止死鎖，一般在佔坑以後還會設置一個過時時間 expire，以下所示：

setnx key value
expire key seconds
複製代碼

以上命令不是一個原子性操做，所謂原子性操做是指命令在執行過程當中並不會被其它的線程或者請求打斷，以上若是 setnx 執行成功以後，出現網絡閃斷 expire 命令便不會獲得執行，會致使死鎖出現。

也許你會想到使用事物來解決，可是事物有個特色，要麼成功要麼失敗，都是一口氣執行完成的，在咱們上面的例子中，expire 是須要先根據 setnx 的結果來判斷是否須要進行設置，顯然事物在這裏是行不通的，社區也有不少庫來解決這個問題，如今 Redis 官方 2.8 版本以後支持 set 命令傳入 setnx、expire 擴展參數，這樣就能夠一條命令一口氣執行，避免了上面的問題，以下所示：

  • value：建議設置爲一個隨機值，在釋放鎖的時候會進一步講解
  • EX seconds：設置的過時時間
  • PX milliseconds：也是設置過時時間，單位不同
  • NX|XX：NX 同 setnx 效果是同樣的
set key value [EX seconds] [PX milliseconds] [NX|XX]
複製代碼

釋放鎖

釋放鎖的過程就是將本來佔有的坑給刪除掉，可是也並不能僅僅使用 del key 刪除掉就萬事大吉了，這樣很容易刪除掉別人的鎖，爲何呢？舉一個例子客戶端 A 獲取到一把 key = name1 的鎖（2 秒中），緊接着處理本身的業務邏輯，可是在業務邏輯處理這塊阻塞了耗時超過了鎖的時間，鎖是會自動被釋放的，這期間該資源又被客戶端 B 獲取了 key = name1 的鎖，那麼客戶端 A 在本身的業務處理結束以後直接使用 del key 命令刪除會把客戶端 B 的鎖給釋放掉了，因此釋放鎖的時候要作到僅釋放本身佔有的鎖。

加鎖的過程當中建議把 value 設置爲一個隨機值，主要是爲了更安全的釋放鎖，在 del key 以前先判斷這個 key 存在且 value 等於本身指定的值才執行刪除操做。判斷和刪除不是一個原子性的操做，此處仍需藉助 Lua 腳本實現。

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

Redis 單實例分佈式鎖 Node.js 實踐

使用 Node.js 的 Redis 客戶端爲 ioredis，npm install ioredis -S 先安裝該包。

初始化自定義 RedisLock

class RedisLock {
    /** * 初始化 RedisLock * @param {*} client * @param {*} options */
    constructor (client, options={}) {
        if (!client) {
            throw new Error('client 不存在');
        }

        if (client.status !== 'connecting') {
            throw new Error('client 未正常連接');
        }

        this.lockLeaseTime = options.lockLeaseTime || 2; // 默認鎖過時時間 2 秒
        this.lockTimeout = options.lockTimeout || 5; // 默認鎖超時時間 5 秒
        this.expiryMode = options.expiryMode || 'EX';
        this.setMode = options.setMode || 'NX';
        this.client = client;
    }
}
複製代碼

上鎖

經過 set 命令傳入 setnx、expire 擴展參數開始上鎖佔坑，上鎖成功返回，上鎖失敗進行重試，在 lockTimeout 指定時間內仍未獲取到鎖，則獲取鎖失敗。

class RedisLock {
    
    /** * 上鎖 * @param {*} key * @param {*} val * @param {*} expire */
    async lock(key, val, expire) {
        const start = Date.now();
        const self = this;

        return (async function intranetLock() {
            try {
                const result = await self.client.set(key, val, self.expiryMode, expire || self.lockLeaseTime, self.setMode);
        
                // 上鎖成功
                if (result === 'OK') {
                    console.log(`${key} ${val} 上鎖成功`);
                    return true;
                }

                // 鎖超時
                if (Math.floor((Date.now() - start) / 1000) > self.lockTimeout) {
                    console.log(`${key} ${val} 上鎖重試超時結束`);
                    return false;
                }

                // 循環等待重試
                console.log(`${key} ${val} 等待重試`);
                await sleep(3000);
                console.log(`${key} ${val} 開始重試`);

                return intranetLock();
            } catch(err) {
                throw new Error(err);
            }
        })();
    }
}
複製代碼

釋放鎖

釋放鎖經過 redis.eval(script) 執行咱們定義的 redis lua 腳本。

class RedisLock {
    /** * 釋放鎖 * @param {*} key * @param {*} val */
    async unLock(key, val) {
        const self = this;
        const script = "if redis.call('get',KEYS[1]) == ARGV[1] then" +
        " return redis.call('del',KEYS[1]) " +
        "else" +
        " return 0 " +
        "end";

        try {
            const result = await self.client.eval(script, 1, key, val);

            if (result === 1) {
                return true;
            }
            
            return false;
        } catch(err) {
            throw new Error(err);
        }
    }
}
複製代碼

測試

這裏使用了 uuid 來生成惟一 ID，這個隨機數 id 只要保證惟一無論用哪一種方式均可。

const Redis = require("ioredis");
const redis = new Redis(6379, "127.0.0.1");
const uuidv1 = require('uuid/v1');
const redisLock = new RedisLock(redis);

function sleep(time) {
    return new Promise((resolve) => {
        setTimeout(function() {
            resolve();
        }, time || 1000);
    });
}

async function test(key) {
    try {
        const id = uuidv1();
        await redisLock.lock(key, id, 20);
        await sleep(3000);
        
        const unLock = await redisLock.unLock(key, id);
        console.log('unLock: ', key, id, unLock);
    } catch (err) {
        console.log('上鎖失敗', err);
    }  
}

test('name1');
test('name1');
複製代碼

同時調用了兩次 test 方法進行上鎖，只有第一個是成功的，第二個 name1 26e02970-0532-11ea-b978-2160dffafa30 上鎖的時候發現 key = name1 已被佔坑，開始重試，因爲以上測試中設置了 3 秒鐘以後自動釋放鎖，name1 26e02970-0532-11ea-b978-2160dffafa30 在通過兩次重試以後上鎖成功。

name1 26e00260-0532-11ea-b978-2160dffafa30 上鎖成功
name1 26e02970-0532-11ea-b978-2160dffafa30 等待重試
name1 26e02970-0532-11ea-b978-2160dffafa30 開始重試
name1 26e02970-0532-11ea-b978-2160dffafa30 等待重試
unLock:  name1 26e00260-0532-11ea-b978-2160dffafa30 true
name1 26e02970-0532-11ea-b978-2160dffafa30 開始重試
name1 26e02970-0532-11ea-b978-2160dffafa30 上鎖成功
unLock:  name1 26e02970-0532-11ea-b978-2160dffafa30 true
複製代碼

源碼地址

https://github.com/Q-Angelo/project-training/tree/master/redis/lock/redislock.js
複製代碼

Redlock 算法

以上是使用 Node.js 對 Redis 分佈式鎖的一個簡單實現，在單實例中是可用的，當咱們對 Redis 節點作一個擴展，在 Sentinel、Redis Cluster 下會怎麼樣呢？

如下是一個 Redis Sentinel 的故障自動轉移示例圖，假設咱們客戶端 A 在主節點 192.168.6.128 獲取到鎖以後，主節點還將來得及同步信息到從節點就掛掉了，這時候 Sentinel 會選舉另一個從節點作爲主節點，那麼客戶端 B 此時也來申請相同的鎖，就會出現一樣一把鎖被多個客戶端持有，對數據的最終一致性有很高的要求仍是不行的。

圖片描述

Redlock 介紹

鑑於這些問題，Redis 官網 redis.io/topics/dist… 提供了一個使用 Redis 實現分佈式鎖的規範算法 Redlock，中文翻譯版參考 redis.cn/topics/dist…

Redlock 在上述文檔也有描述，這裏簡單作個總結：Redlock 在 Redis 單實例或多實例中提供了強有力的保障，自己具有容錯能力，它會從 N 個實例使用相同的 key、隨機值嘗試 set key value [EX seconds] [PX milliseconds] [NX|XX] 命令去獲取鎖，在有效時間內至少 N/2+1 個 Redis 實例取到鎖，此時就認爲取鎖成功，不然取鎖失敗，失敗狀況下客戶端應該在全部的 Redis 實例上進行解鎖。

Node.js 中應用 Redlock

github.com/mike-marcac… 是 Node.js 版的 Redlock 實現，使用起來也很簡單，開始以前先安裝 ioredis、redlock 包。

npm i ioredis -S
npm i redlock -S
複製代碼

編碼

const Redis = require("ioredis");
const client1 = new Redis(6379, "127.0.0.1");
const Redlock = require('redlock');
const redlock = new Redlock([client1], {
    retryDelay: 200, // time in ms
    retryCount: 5,
});

// 多個 Redis 實例
// const redlock = new Redlock(
// [new Redis(6379, "127.0.0.1"), new Redis(6379, "127.0.0.2"), new Redis(6379, "127.0.0.3")],
// )

async function test(key, ttl, client) {
    try {
        const lock = await redlock.lock(key, ttl);

        console.log(client, lock.value);
        // do something ...

        // return lock.unlock();
    } catch(err) {
        console.error(client, err);
    }
}

test('name1', 10000, 'client1');
test('name1', 10000, 'client2');
複製代碼

測試

對同一個 key name1 兩次上鎖，因爲 client1 先取到了鎖，client2 沒法獲取鎖，重試 5 次以後報錯 LockError: Exceeded 5 attempts to lock the resource "name1".

圖片描述
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程