緩存擊穿

【問題描述】：

緩存里沒數(shù)據(jù)，但是數(shù)據(jù)庫里面有數(shù)據(jù)。大批量數(shù)據(jù)在同一時間時間，在數(shù)據(jù)過期后突然被大量請求，導(dǎo)致緩存被擊穿，糟踏數(shù)據(jù)庫。

【解決辦法】：

對超時時間設(shè)置為隨機(jī)，避免同一時間大量數(shù)據(jù)過期。

緩存穿透?

【問題原因】：?

假設(shè)在一個秒殺系統(tǒng)下，誤刪了數(shù)據(jù)庫中某一個商品，大量請求在緩存中沒有找到數(shù)據(jù)，這就會去數(shù)據(jù)庫里面找，但是數(shù)據(jù)庫里面也沒有，最終導(dǎo)致數(shù)據(jù)庫抗不住壓力。這就是緩存穿透，緩存穿透會將所有后端所有存儲層都穿透掉。影響：實際數(shù)據(jù)庫中沒有數(shù)據(jù)，卻還有大量請求不斷涌進(jìn)來，透緩存，透數(shù)據(jù)庫。

【解決辦法】：

對無效的數(shù)據(jù)在緩存中設(shè)置一個空值。當(dāng)首次請求來時，在數(shù)據(jù)庫中查詢到數(shù)據(jù)則在緩存中緩存真實的值，沒有數(shù)據(jù)放一個空值。

突發(fā)性的熱點緩存重建導(dǎo)致系統(tǒng)壓力暴增問題

【問題原因】：?

在電商直播環(huán)境下，大V直播間推薦某一款冷門商品，主播一上鏈接，大量用戶訪問這個商品，恰巧這個商品不在緩存中，那么就會導(dǎo)致大量數(shù)據(jù)擊穿緩存，糟蹋數(shù)據(jù)庫。

不確定某個商品、或微博熱搜在什么時間下，數(shù)據(jù)量暴增

【解決辦法】：

雙重檢測機(jī)制（DCL）。在第一次沒有數(shù)據(jù)時，使用加鎖處理重建。使用分布式鎖對查詢的數(shù)據(jù)做緩存重建。使用jedisson分布式鎖。

并發(fā)重建鎖優(yōu)化： hotCacheCreateLock.tryLock(2，TimeUnit.SECONDS);

緩存與數(shù)據(jù)庫雙寫不一致問題

【問題描述】：

兩條線程依次執(zhí)行數(shù)據(jù)庫余額更新操作，正常情況下，線程要把余額更新成6，線程2再更新成5。但是在高并發(fā)復(fù)雜的環(huán)境下，線程1稍微晚一秒中執(zhí)行，被線程2先執(zhí)行完把數(shù)據(jù)更新成了5，此時線程1在執(zhí)行跟新則會把5改成6。

【解決辦法】：

使用分布式事務(wù)鎖解決。針對獲取數(shù)據(jù)時和更新時加鎖處理，最后使用讀寫鎖優(yōu)化。針對讀多寫少的場景進(jìn)行分離，使讀操作可以并行，寫操作進(jìn)行互斥。

redis實現(xiàn)讀寫鎖： redisson.getReadWriteLock();

雪崩問題

【問題描述】：

redis撐死處理十萬+數(shù)據(jù)，在單節(jié)點下經(jīng)受不住突如其來的幾十或幾百萬條請求，即使集群也無法分擔(dān)壓力。由于緩存宕機(jī)，導(dǎo)致應(yīng)用服務(wù)一個奔潰。

【解決辦法】：

限流。多級緩存架構(gòu)：jvm進(jìn)程緩存（缺點1.無法放大量數(shù)據(jù) 2.數(shù)據(jù)不一致）。