Redis——由分佈式鎖形成的重大事故

時間 2020-07-23

原文原文鏈接

前言

基於Redis使用分佈式鎖在當今已經不是什麼新鮮事了。本篇文章主要是基於咱們實際項目中由於redis分佈式鎖形成的事故分析及解決方案。
背景：咱們項目中的搶購訂單採用的是分佈式鎖來解決的。有一次，運營作了一個飛天茅臺的搶購活動，庫存100瓶，可是卻超賣了！要知道，這個地球上飛天茅臺的稀缺性啊！！！事故定爲P0級重大事故...只能坦然接受。整個項目組被扣績效了~~事故發生後，CTO指名點姓讓我帶頭衝鋒來處理，好吧，衝~java

事故現場

通過一番瞭解後，得知這個搶購活動接口之前歷來沒有出現過這種狀況，可是此次爲何會超賣呢？緣由在於：以前的搶購商品都不是什麼稀缺性商品，而此次活動竟然是飛天茅臺，經過埋點數據分析，各項數據基本都是成倍增加，活動熱烈程度可想而知！話很少說，直接上核心代碼，機密部分作了僞代碼處理。。。redis

public SeckillActivityRequestVO seckillHandle(SeckillActivityRequestVO request) {
SeckillActivityRequestVO response;
    String key = "key:" + request.getSeckillId;
    try {
        Boolean lockFlag = redisTemplate.opsForValue().setIfAbsent(key, "val", 10, TimeUnit.SECONDS);
        if (lockFlag) {
            // HTTP請求用戶服務進行用戶相關的校驗
            // 用戶活動校驗
            
            // 庫存校驗
            Object stock = redisTemplate.opsForHash().get(key+":info", "stock");
            assert stock != null;
            if (Integer.parseInt(stock.toString()) <= 0) {
                // 業務異常
            } else {
                redisTemplate.opsForHash().increment(key+":info", "stock", -1);
                // 生成訂單
                // 發佈訂單建立成功事件
                // 構建響應VO
            }
        }
    } finally {
        // 釋放鎖
        stringRedisTemplate.delete("key");
        // 構建響應VO
    }
    return response;
}
複製代碼

以上代碼，經過分佈式鎖過時時間有效期10s來保障業務邏輯有足夠的執行時間；採用try-finally語句塊保證鎖必定會及時釋放。業務代碼內部也對庫存進行了校驗。看起來很安全啊~ 別急，繼續分析。。。算法

事故緣由

飛天茅臺搶購活動吸引了大量新用戶下載註冊咱們的APP，其中，不乏不少羊毛黨，採用專業的手段來註冊新用戶來薅羊毛和刷單。固然咱們的用戶系統提早作好了防備，接入阿里雲人機驗證、三要素認證以及自研的風控系統等各類十八般武藝，擋住了大量的非法用戶。此處不由點個贊~
但也正因如此，讓用戶服務一直處於較高的運行負載中。
搶購活動開始的一瞬間，大量的用戶校驗請求打到了用戶服務。致使用戶服務網關出現了短暫的響應延遲，有些請求的響應時長超過了10s，但因爲HTTP請求的響應超時咱們設置的是30s，這就致使接口一直阻塞在用戶校驗那裏，10s後，分佈式鎖已經失效了，此時有新的請求進來是能夠拿到鎖的，也就是說鎖被覆蓋了。這些阻塞的接口執行完以後，又會執行釋放鎖的邏輯，這就把其餘線程的鎖釋放了，致使新的請求也能夠競爭到鎖~這真是一個極其惡劣的循環。
這個時候只能依賴庫存校驗，可是恰恰庫存校驗不是非原子性的，採用的是get and compare 的方式，超賣的悲劇就這樣發生了~~~緩存

事故分析

仔細分析下來，能夠發現，這個搶購接口在高併發場景下，是有嚴重的安全隱患的，主要集中在三個地方：安全

沒有其餘系統風險容錯處理
因爲用戶服務吃緊，網關響應延遲，但沒有任何應對方式，這是超賣的導火索。
看似安全的分佈式鎖其實一點都不安全
雖然採用了set key value [EX seconds] [PX milliseconds] [NX|XX]的方式，可是若是線程A執行的時間較長沒有來得及釋放，鎖就過時了，此時線程B是能夠獲取到鎖的。當線程A執行完成以後，釋放鎖，實際上就把線程B的鎖釋放掉了。這個時候，線程C又是能夠獲取到鎖的，而此時若是線程B執行完釋放鎖實際上就是釋放的線程C設置的鎖。這是超賣的直接緣由。
非原子性的庫存校驗
非原子性的庫存校驗致使在併發場景下，庫存校驗的結果不許確。這是超賣的根本緣由。

經過以上分析，問題的根本緣由在於庫存校驗嚴重依賴了分佈式鎖。由於在分佈式鎖正常set、del的狀況下，庫存校驗是沒有問題的。可是，當分佈式鎖不安全可靠的時候，庫存校驗就沒有用了。服務器

解決方案

知道了緣由以後，咱們就能夠對症下藥了。併發

實現相對安全的分佈式鎖

相對安全的定義：set、del是一一映射的，不會出現把其餘現成的鎖del的狀況。從實際狀況的角度來看，即便能作到set、del一一映射，也沒法保障業務的絕對安全。由於鎖的過時時間始終是有界的，除非不設置過時時間或者把過時時間設置的很長，但這樣作也會帶來其餘問題。故沒有意義。
要想實現相對安全的分佈式鎖，必須依賴key的value值。在釋放鎖的時候，經過value值的惟一性來保證不會勿刪。咱們基於LUA腳本實現原子性的get and compare，以下：dom

public void safedUnLock(String key, String val) {
    String luaScript = "local in = ARGV[1] local curr=redis.call('get', KEYS[1]) if in==curr then redis.call('del', KEYS[1]) end return 'OK'"";
    RedisScript<String> redisScript = RedisScript.of(luaScript);
    redisTemplate.execute(redisScript, Collections.singletonList(key), Collections.singleton(val));
}
複製代碼

咱們經過LUA腳原本實現安全地解鎖。分佈式

實現安全的庫存校驗

若是咱們對於併發有比較深刻的瞭解的話，會發現想 get and compare/ read and save 等操做，都是非原子性的。若是要實現原子性，咱們也能夠藉助LUA腳原本實現。但就咱們這個例子中，因爲搶購活動一單隻能下1瓶，所以能夠不用基於LUA腳本實現而是基於redis自己的原子性。緣由在於：高併發

// redis會返回操做以後的結果，這個過程是原子性的
Long currStock = redisTemplate.opsForHash().increment("key", "stock", -1);
複製代碼

發現沒有，代碼中的庫存校驗徹底是「多此一舉」。

改進以後的代碼

通過以上的分析以後，咱們決定新建一個DistributedLocker類專門用於處理分佈式鎖。

public SeckillActivityRequestVO seckillHandle(SeckillActivityRequestVO request) {
SeckillActivityRequestVO response;
    String key = "key:" + request.getSeckillId();
    String val = UUID.randomUUID().toString();
    try {
        Boolean lockFlag = distributedLocker.lock(key, val, 10, TimeUnit.SECONDS);
        if (!lockFlag) {
            // 業務異常
        }

        // 用戶活動校驗
        // 庫存校驗，基於redis自己的原子性來保證
        Long currStock = stringRedisTemplate.opsForHash().increment(key + ":info", "stock", -1);
        if (currStock < 0) { // 說明庫存已經扣減完了。
            // 業務異常。
            log.error("[搶購下單] 無庫存");
        } else {
            // 生成訂單
            // 發佈訂單建立成功事件
            // 構建響應
        }
    } finally {
        distributedLocker.safedUnLock(key, val);
        // 構建響應
    }
    return response;
}
複製代碼

深度思考

分佈式鎖有必要麼

改進以後，其實能夠發現，咱們藉助於redis自己的原子性扣減庫存，也是能夠保證不會超賣的。對的。可是若是沒有這一層鎖的話，那麼全部請求進來都會走一遍業務邏輯，因爲依賴了其餘系統，此時就會形成對其餘系統的壓力增大。這會增長的性能損耗和服務不穩定性，得不償失。基於分佈式鎖能夠在必定程度上攔截一些流量。

分佈式鎖的選型

有人提出用RedLock來實現分佈式鎖。RedLock的可靠性更高，但其代價是犧牲必定的性能。在本場景，這點可靠性的提高遠不如性能的提高帶來的性價比高。若是對於可靠性極高要求的場景，則能夠採用RedLock來實現。

再次思考分佈式鎖有必要麼

因爲bug須要緊急修復上線，所以咱們將其優化並在測試環境進行了壓測以後，就立馬熱部署上線了。實際證實，這個優化是成功的，性能方面略微提高了一些，並在分佈式鎖失效的狀況下，沒有出現超賣的狀況。
然而，還有沒有優化空間呢？有的！
因爲服務是集羣部署，咱們能夠將庫存均攤到集羣中的每一個服務器上，經過廣播通知到集羣的各個服務器。網關層基於用戶ID作hash算法來決定請求到哪一臺服務器。這樣就能夠基於應用緩存來實現庫存的扣減和判斷。性能又進一步提高了！

// 經過消息提早初始化好，藉助ConcurrentHashMap實現高效線程安全
private static ConcurrentHashMap<Long, Boolean> SECKILL_FLAG_MAP = new ConcurrentHashMap<>();
// 經過消息提早設置好。因爲AtomicInteger自己具有原子性，所以這裏能夠直接使用HashMap
private static Map<Long, AtomicInteger> SECKILL_STOCK_MAP = new HashMap<>();

...

public SeckillActivityRequestVO seckillHandle(SeckillActivityRequestVO request) {
SeckillActivityRequestVO response;

    Long seckillId = request.getSeckillId();
    if(!SECKILL_FLAG_MAP.get(requestseckillId)) {
        // 業務異常
    }
     // 用戶活動校驗
     // 庫存校驗
    if(SECKILL_STOCK_MAP.get(seckillId).decrementAndGet() < 0) {
        SECKILL_FLAG_MAP.put(seckillId, false);
        // 業務異常
    }
    // 生成訂單
    // 發佈訂單建立成功事件
    // 構建響應
    return response;
}
複製代碼

經過以上的改造，咱們就徹底不須要依賴redis了。性能和安全性兩方面都能進一步獲得提高！
固然，此方案沒有考慮到機器的動態擴容、縮容等複雜場景，若是還要考慮這些話，則不如直接考慮分佈式鎖的解決方案。

總結

稀缺商品超賣絕對是重大事故。若是超賣數量多的話，甚至會給平臺帶來很是嚴重的經營影響和社會影響。通過本次事故，讓我意識到對於項目中的任何一行代碼都不能掉以輕心，不然在某些場景下，這些正常工做的代碼就會變成致命殺手！對於一個開發者而言，則設計開發方案時，必定要將方案考慮周全。怎樣才能將方案考慮周全？惟有持續不斷地學習！