這篇具有很好參考價(jià)值的文章主要介紹了Redis - 做緩存時(shí)高并發(fā)問題：緩存穿透、擊穿、雪崩，數(shù)據(jù)庫緩存雙寫不一致。希望對(duì)大家有所幫助。如果存在錯(cuò)誤或未考慮完全的地方，請(qǐng)大家不吝賜教，您也可以點(diǎn)擊"舉報(bào)違法"按鈕提交疑問。
緩存穿透
當(dāng)用戶訪問的數(shù)據(jù)既不在緩存也不在數(shù)據(jù)庫中時(shí)，就會(huì)導(dǎo)致每個(gè)用戶查詢都會(huì)“穿透”
緩存“直抵”數(shù)據(jù)庫。這種情況就稱為緩存穿透。當(dāng)高度發(fā)的訪問請(qǐng)求到達(dá)時(shí)，緩存穿透不
僅增加了響應(yīng)時(shí)間，而且還會(huì)引發(fā)對(duì)
DBMS
的高并發(fā)查詢，這種高并發(fā)查詢很可能會(huì)導(dǎo)致
DBMS
的崩潰。
緩存穿透產(chǎn)生的主要原因有兩個(gè)：一是在數(shù)據(jù)庫中沒有相應(yīng)的查詢結(jié)果，二是查詢結(jié)果
為空時(shí)，不對(duì)查詢結(jié)果進(jìn)行緩存。所以，針對(duì)以上兩點(diǎn)，解決方案也有兩個(gè)：
?
對(duì)非法請(qǐng)求進(jìn)行限制
?
對(duì)結(jié)果為空的查詢給出默認(rèn)值
緩存擊穿
對(duì)于某一個(gè)緩存，在高并發(fā)情況下若其訪問量特別巨大，當(dāng)該緩存的有效時(shí)限到達(dá)時(shí)，
可能會(huì)出現(xiàn)大量的訪問都要重建該緩存，即這些訪問請(qǐng)求發(fā)現(xiàn)緩存中沒有該數(shù)據(jù)，則立即到
DBMS
中進(jìn)行查詢，那么這就有可能會(huì)引發(fā)對(duì)
DBMS
的高并發(fā)查詢，從而接導(dǎo)致
DBMS
的崩
潰。這種情況稱為緩存擊穿，而該緩存數(shù)據(jù)稱為熱點(diǎn)數(shù)據(jù)。
對(duì)于緩存擊穿的解決方案，較典型的是使用“雙重檢測(cè)鎖”機(jī)制。
// 使用雙重檢測(cè)鎖機(jī)制預(yù)防緩存擊穿
// 若緩存中沒有該數(shù)據(jù)，則先從DB中查詢，然后再寫入到緩存
if (turnover == null) {
synchronized (this) {
turnover = ops.get();
if (turnover == null) {
// 獲取當(dāng)前日期，并格式化
Date date = new Date();
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
turnover = dao.selectTurnover(sdf.format(date));
// 將查詢結(jié)果寫入到緩存
ops.set(turnover, 10, TimeUnit.SECONDS);
}
}
}
緩存雪崩
對(duì)于緩存中的數(shù)據(jù)，很多都是有過期時(shí)間的。若大量緩存的過期時(shí)間在同一很短的時(shí)間
段內(nèi)幾乎同時(shí)到達(dá)，那么在高并發(fā)訪問場(chǎng)景下就可能會(huì)引發(fā)對(duì)
DBMS
的高并發(fā)查詢，而這將
可能直接導(dǎo)致
DBMS
的崩潰。這種情況稱為緩存雪崩。
對(duì)于緩存雪崩沒有很直接的解決方案，最好的解決方案就是預(yù)防，即提前規(guī)劃好緩存的
過期時(shí)間。要么就是讓緩存永久有效，當(dāng)
DB
中數(shù)據(jù)發(fā)生變化時(shí)清除相應(yīng)的緩存。如果
DBMS
采用的是分布式部署，則將熱點(diǎn)數(shù)據(jù)均勻分布在不同數(shù)據(jù)庫節(jié)點(diǎn)中，將可能到來的訪問負(fù)載
均衡開來。
數(shù)據(jù)庫緩存雙寫不一致
以上三種情況都是針對(duì)
高并發(fā)讀
場(chǎng)景中可能會(huì)出現(xiàn)的問題，而數(shù)據(jù)庫緩存雙寫不一致問
題，則是在
高并發(fā)寫
場(chǎng)景下可能會(huì)出現(xiàn)的問題。
對(duì)于數(shù)據(jù)庫緩存雙寫不一致問題，以下兩種場(chǎng)景下均有可能會(huì)發(fā)生：
“
修改
DB
更新緩存
”
場(chǎng)景
對(duì)于具有緩存
warmup
功能的系統(tǒng)，
DBMS
中常用數(shù)據(jù)的變更，都會(huì)引發(fā)緩存中相關(guān)數(shù)
據(jù)的更新。在高并發(fā)
寫
請(qǐng)求場(chǎng)景下，若多個(gè)請(qǐng)求要對(duì)
DBMS
中同一個(gè)數(shù)據(jù)進(jìn)行修改，修改后
還需要更新緩存中相關(guān)數(shù)據(jù)，那么就有可能會(huì)出現(xiàn)緩存與數(shù)據(jù)庫中數(shù)據(jù)不一致的情況。
“
修改
DB
刪除緩存
”
場(chǎng)景
在很多系統(tǒng)中是沒有緩存
warmup
功能的，為了保持緩存與數(shù)據(jù)庫數(shù)據(jù)的一致性，一般
都是在對(duì)數(shù)據(jù)庫執(zhí)行了寫操作后，就會(huì)刪除相應(yīng)緩存。
在高并發(fā)
讀寫
請(qǐng)求場(chǎng)景下，若這些請(qǐng)求對(duì)
DBMS
中同一個(gè)數(shù)據(jù)的操作既包含寫也包含讀，
且修改后還要?jiǎng)h除緩存中相關(guān)數(shù)據(jù)，那么就有可能會(huì)出現(xiàn)緩存與數(shù)據(jù)庫中數(shù)據(jù)不一致的情況。
解決方案：延遲雙刪
延遲雙刪方案是專門針對(duì)于“修改
DB
刪除緩存”場(chǎng)景的解決方案。但該方案并不能徹
底解決數(shù)據(jù)不一致的狀況，其只可能降低發(fā)生數(shù)據(jù)不一致的概率。
延遲雙刪方案是指，在寫操作完畢后會(huì)立即執(zhí)行一次緩存的刪除操作，然后再停上一段
時(shí)間（一般為幾秒）后再進(jìn)行一次刪除。而兩次刪除中間的間隔時(shí)長(zhǎng)，要大于一次緩存寫操
作的時(shí)長(zhǎng)。
解決方案：隊(duì)列
以上兩種場(chǎng)景中，只所以會(huì)出現(xiàn)數(shù)據(jù)庫與緩存中數(shù)據(jù)不一致，主要是因?yàn)閷?duì)請(qǐng)求的處理出現(xiàn)了并行。只要將請(qǐng)求寫入到一個(gè)統(tǒng)一的隊(duì)列，只有處理完一個(gè)請(qǐng)求后才可處理下一個(gè)請(qǐng)求，即使系統(tǒng)對(duì)用戶請(qǐng)求的處理串行化，就可以完全解決數(shù)據(jù)不一致的問題。
解決方案：分布式鎖
使用隊(duì)列的串行化雖然可以解決數(shù)據(jù)庫與緩存中數(shù)據(jù)不一致，但系統(tǒng)失去了并發(fā)性，降低了性能。使用分布式鎖可以在不影響并發(fā)性的前提下，協(xié)調(diào)各處理線程間的關(guān)系，使數(shù)據(jù)庫與緩存中的數(shù)據(jù)達(dá)成一致性。文章來源：http://www.zghlxwxcb.cn/news/detail-758900.html
只需要對(duì)數(shù)據(jù)庫中的這個(gè)共享數(shù)據(jù)的訪問通過分布式鎖來協(xié)調(diào)對(duì)其的操作訪問即可。文章來源地址http://www.zghlxwxcb.cn/news/detail-758900.html
到了這里，關(guān)于Redis - 做緩存時(shí)高并發(fā)問題：緩存穿透、擊穿、雪崩，數(shù)據(jù)庫緩存雙寫不一致的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
本文來自互聯(lián)網(wǎng)用戶投稿，該文觀點(diǎn)僅代表作者本人，不代表本站立場(chǎng)。本站僅提供信息存儲(chǔ)空間服務(wù)，不擁有所有權(quán)，不承擔(dān)相關(guān)法律責(zé)任。如若轉(zhuǎn)載，請(qǐng)注明出處： 如若內(nèi)容造成侵權(quán)/違法違規(guī)/事實(shí)不符，請(qǐng)點(diǎn)擊違法舉報(bào)進(jìn)行投訴反饋，一經(jīng)查實(shí)，立即刪除！
