緩存擊穿，Redis中的某個熱點key不存在或者過期，但是此時有大量的用戶訪問該key。比如xxx直播間優惠券搶購、xxx商品活動，這時候大量用戶會在某個時間點一同訪問該熱點事件。但是可能由于某種原因，redis的這個熱點key沒有設置，或者過期了，那么這時候大量高并發對于該key的請求就得不到redis的響應，那么就會將請求直接打在DB服務器上，造成DB突刺，CPU和內存瞬間被打滿，最終導致服務崩潰。

本人所負責的業務就存在這樣的場景，以直播間邀請榜單為例，顧名思義就是會查詢該直播間實時的邀請人數，統計前30名邀請人數最多的用戶展示在直播間里面，通過榜單去刺激C端用戶的分享參與熱情。下面一起分析下這個場景遇到的問題和解決方案。

問題1：
統計邀請榜單需要加載實時的，即我邀請一個人進來，假設在前30名，那我不得上榜嗎？那問題來了，這種數據我是不是得實時去查數據庫呢？

解決方案：這種業務，我們一般會設置一個短時間的緩存，比如30秒左右。也就是在緩存失效后，即30秒去查一次數據庫，不然數據庫肯定是頂不住的。

問題2：
我們常規的設置緩存的代碼邏輯可能是下面這種。（代碼片段錯誤處理等細節請自行處理，這是一段精簡版的代碼，主要介紹Redis的處理邏輯）

//step1:讀緩存，存在則返回結果
ctx := context.Background()

rdb := redis.NewClient(&redis.Options{
Addr:     "localhost:6379",
Password: "123456",
DB:       0,
})

redisKey := "xxx_xxx_xxx" //邀請榜單數據的key

res, err := rdb.Get(ctx, redisKey).Result()
if err == nil {
return res
}

//step2:不存在緩存，讀DB
//此處省略，查DB的數據，結果為res

//step3:設置緩存，并返回結果
args := redis.SetArgs{
TTL:  time.Second * 30,
Mode: "EX",
}
_, _ = rdb.SetArgs(ctx, redisKey, res, args).Result()

return res

這種代碼邏輯在并發量小的情況下是沒有任何問題的，事實上我平時寫一些業務，基本上就把它當成一個“公式”來用，用的非常多。然而，在一些高并發的場景下，這種邏輯就會出現問題。試想一下這個場景：假如某個大直播（用戶量巨大）是在晚上8點開播，那么8點一到，那個瞬間就會有大量的C端用戶進入直播間，去調用后端的接口，假如此時接口的Redis緩存已經過期或者不存在，那么這一刻就會有大量的請求落到DB上，可想而知這一刻DB的壓力是多么巨大（這誰頂得住啊）。這就是一個典型的緩存擊穿的業務場景。
那么我們需要怎么做，才能讓我們的服務抵抗住瞬時的請求洪峰呢？

解決方案：
解決緩存擊穿的常見方法有幾種：
1、設置該key永不過期，那么就不會存在緩存失效、過期等問題。但這種方法很明顯不適合我這種場景，因為我上面提到過，我這個key值存的是邀請榜單的數據，是動態更新的，在直播中，這個榜單的數據是會變化的，所以只能設30秒的緩存時間。該方案行不通。

2、人工干預該key，比如寫一個腳本去定時讀DB數據，然后更新這個key，然后業務側（對接前端的接口）只能通過讀該key的緩存去獲取結果數據，而不能直接讀DB。這樣也能解決問題，但是貌似維護成本有點高，而且業務側不能讀DB也很不靈活，你想下如果每個熱點key都這樣去設置維護，那估計會很煩吧。該方案也行不通。

3、使用互斥鎖，即在緩存失效的時候，只有一個請求可以獲取到互斥鎖，然后去查DB，最后重建緩存。這種方案就能很好地解決緩存擊穿這個問題，也是我在工作中用來應對緩存擊穿問題的最常用的方案。下面是精簡版代碼：

//step1:讀緩存，存在則返回結果
ctx := context.Background()

rdb := redis.NewClient(&redis.Options{
Addr:     "localhost:6379",
Password: "123456",
DB:       0,
})

redisKey := "xxx_xxx_xxx" //邀請榜單數據的key

res, err := rdb.Get(ctx, redisKey).Result()
if err == nil {
return res
}

//step2:不存在緩存，加互斥鎖，讀緩存
lockKey := "yyy_yyy_yyy" //互斥鎖的key

argsLock := redis.SetArgs{
TTL:  time.Second * 3,
Mode: "NX", //不存在時才執行
}

_, err = rdb.SetArgs(ctx, lockKey, "1", argsLock).Result()
if err != nil { //獲取互斥鎖失敗
for i := 0; i < 3; i++ { //重復三次去讀緩存值
res, errRetry := rdb.Get(ctx, redisKey).Result()
if errRetry == nil { //重試讀緩存成功，則返回結果
return res 
}
time.Sleep(10 * time.Millisecond) //這里睡眠時間根據業務來定，取的是另一個線程從讀數據庫到設置緩存成功的大概時間區間
}
return nil //如果循環三次，都讀不到緩存，則返回空結果
}

//step3:獲取互斥鎖成功，則表明當前的線程/協程擁有查DB的權力
//此處省略，查DB的數據，結果為res

//step4:設置緩存，刪除互斥鎖，并返回結果
args := redis.SetArgs{
TTL:  time.Second * 30,
Mode: "EX",
}
_, _ = rdb.SetArgs(ctx, redisKey, res, args).Result()

rdb.Del(ctx, lockKey) //刪除互斥鎖

return res

以上就是個人在線上的一些項目面對緩存擊穿問題，所做的一些處理方案了。當然這個方案也不是完美的，例如當獲取到互斥鎖的當前線程/協程，出現異常，導致設置緩存失敗，那么其他線程/協程就重試3次可能都獲取不到正常結果，最后返回了一個空結果給前端。感興趣的朋友可以想想這個方案還有什么問題，然后能怎么優化，歡迎指出。

一個人可以被毀滅，但不可以被打敗。

鏈接：https://www.cnblogs.com/lmz-blogs/p/18173813