Redis分佈式鎖之紅鎖的實現

一、問題

分佈式鎖,當我們請求一個分佈式鎖的時候,成功瞭,但是這時候slave還沒有復制我們的鎖,masterDown瞭,我們的應用繼續請求鎖的時候,會從繼任瞭master的原slave上申請,也會成功。

這就會導致,同一個鎖被獲取瞭不止一次。

二、辦法

Redis中針對此種情況,引入瞭紅鎖的概念。

三、原理

用Redis中的多個master實例,來獲取鎖,隻有大多數實例獲取到瞭鎖,才算是獲取成功。具體的紅鎖算法分為以下五步:

  • 獲取當前的時間(單位是毫秒)。
  • 使用相同的key和隨機值在N個節點上請求鎖。這裡獲取鎖的嘗試時間要遠遠小於鎖的超時時間,防止某個masterDown瞭,我們還在不斷的獲取鎖,而被阻塞過長的時間。
  • 隻有在大多數節點上獲取到瞭鎖,而且總的獲取時間小於鎖的超時時間的情況下,認為鎖獲取成功瞭。
  • 如果鎖獲取成功瞭,鎖的超時時間就是最初的鎖超時時間進去獲取鎖的總耗時時間。
  • 如果鎖獲取失敗瞭,不管是因為獲取成功的節點的數目沒有過半,還是因為獲取鎖的耗時超過瞭鎖的釋放時間,都會將已經設置瞭key的master上的key刪除。

四、實戰

Redission就實現瞭紅鎖算法,使用的步驟如下:

1、引入maven

<!-- JDK 1.8+ compatible -->
<dependency>
   <groupId>org.redisson</groupId>
   <artifactId>redisson</artifactId>
   <version>3.9.0</version>
</dependency> 

2、引入代碼

Config config1 = new Config();
config1.useSingleServer().setAddress("redis://172.0.0.1:5378").setPassword("a123456").setDatabase(0);
RedissonClient redissonClient1 = Redisson.create(config1);

Config config2 = new Config();
config2.useSingleServer().setAddress("redis://172.0.0.1:5379").setPassword("a123456").setDatabase(0);
RedissonClient redissonClient2 = Redisson.create(config2);

Config config3 = new Config();
config3.useSingleServer().setAddress("redis://172.0.0.1:5380").setPassword("a123456").setDatabase(0);
RedissonClient redissonClient3 = Redisson.create(config3);

/**
 * 獲取多個 RLock 對象
 */
RLock lock1 = redissonClient1.getLock(lockKey);
RLock lock2 = redissonClient2.getLock(lockKey);
RLock lock3 = redissonClient3.getLock(lockKey);

/**
 * 根據多個 RLock 對象構建 RedissonRedLock (最核心的差別就在這裡)
 */
RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);

try {
    /**
     * 4.嘗試獲取鎖
     * waitTimeout 嘗試獲取鎖的最大等待時間,超過這個值,則認為獲取鎖失敗
     * leaseTime   鎖的持有時間,超過這個時間鎖會自動失效(值應設置為大於業務處理的時間,確保在鎖有效期內業務能處理完)
     */
    boolean res = redLock.tryLock((long)waitTimeout, (long)leaseTime, TimeUnit.SECONDS);
    if (res) {
        //成功獲得鎖,在這裡處理業務
    }
} catch (Exception e) {
    throw new RuntimeException("aquire lock fail");
}finally{
    //無論如何, 最後都要解鎖
    redLock.unlock();
}

3、核心源碼

public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
    long newLeaseTime = -1;
    if (leaseTime != -1) {
        newLeaseTime = unit.toMillis(waitTime)*2;
    }
    
    long time = System.currentTimeMillis();
    long remainTime = -1;
    if (waitTime != -1) {
        remainTime = unit.toMillis(waitTime);
    }
    long lockWaitTime = calcLockWaitTime(remainTime);
    /**
     * 1. 允許加鎖失敗節點個數限制(N-(N/2+1))
     */
    int failedLocksLimit = failedLocksLimit();
    /**
     * 2. 遍歷所有節點通過EVAL命令執行lua加鎖
     */
    List<RLock> acquiredLocks = new ArrayList<>(locks.size());
    for (ListIterator<RLock> iterator = locks.listIterator(); iterator.hasNext();) {
        RLock lock = iterator.next();
        boolean lockAcquired;
        /**
         *  3.對節點嘗試加鎖
         */
        try {
            if (waitTime == -1 && leaseTime == -1) {
                lockAcquired = lock.tryLock();
            } else {
                long awaitTime = Math.min(lockWaitTime, remainTime);
                lockAcquired = lock.tryLock(awaitTime, newLeaseTime, TimeUnit.MILLISECONDS);
            }
        } catch (RedisResponseTimeoutException e) {
            // 如果拋出這類異常,為瞭防止加鎖成功,但是響應失敗,需要解鎖所有節點
            unlockInner(Arrays.asList(lock));
            lockAcquired = false;
        } catch (Exception e) {
            // 拋出異常表示獲取鎖失敗
            lockAcquired = false;
        }
        
        if (lockAcquired) {
            /**
             *4. 如果獲取到鎖則添加到已獲取鎖集合中
             */
            acquiredLocks.add(lock);
        } else {
            /**
             * 5. 計算已經申請鎖失敗的節點是否已經到達 允許加鎖失敗節點個數限制 (N-(N/2+1))
             * 如果已經到達, 就認定最終申請鎖失敗,則沒有必要繼續從後面的節點申請瞭
             * 因為 Redlock 算法要求至少N/2+1 個節點都加鎖成功,才算最終的鎖申請成功
             */
            if (locks.size() - acquiredLocks.size() == failedLocksLimit()) {
                break;
            }

            if (failedLocksLimit == 0) {
                unlockInner(acquiredLocks);
                if (waitTime == -1 && leaseTime == -1) {
                    return false;
                }
                failedLocksLimit = failedLocksLimit();
                acquiredLocks.clear();
                // reset iterator
                while (iterator.hasPrevious()) {
                    iterator.previous();
                }
            } else {
                failedLocksLimit--;
            }
        }

        /**
         * 6.計算 目前從各個節點獲取鎖已經消耗的總時間,如果已經等於最大等待時間,則認定最終申請鎖失敗,返回false
         */
        if (remainTime != -1) {
            remainTime -= System.currentTimeMillis() - time;
            time = System.currentTimeMillis();
            if (remainTime <= 0) {
                unlockInner(acquiredLocks);
                return false;
            }
        }
    }

    if (leaseTime != -1) {
        List<RFuture<Boolean>> futures = new ArrayList<>(acquiredLocks.size());
        for (RLock rLock : acquiredLocks) {
            RFuture<Boolean> future = ((RedissonLock) rLock).expireAsync(unit.toMillis(leaseTime), TimeUnit.MILLISECONDS);
            futures.add(future);
        }
        
        for (RFuture<Boolean> rFuture : futures) {
            rFuture.syncUninterruptibly();
        }
    }

    /**
     * 7.如果邏輯正常執行完則認為最終申請鎖成功,返回true
     */
    return true;
}

到此這篇關於Redis分佈式鎖之紅鎖的實現的文章就介紹到這瞭,更多相關Redis 紅鎖內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: