Redis面試常見問答
1. 什么是緩存雪崩?怎么解決?
通常,我們會(huì)使用緩存用于緩沖對(duì) DB 的沖擊,如果緩存宕機(jī),所有請(qǐng)求將直接打在 DB,造成 DB 宕機(jī)——從而導(dǎo)致整個(gè)系統(tǒng)宕機(jī)。
如何解決呢?
2 種策略(同時(shí)使用):
- 對(duì)緩存做高可用,防止緩存宕機(jī)
- 使用斷路器,如果緩存宕機(jī),為了防止系統(tǒng)全部宕機(jī),限制部分流量進(jìn)入 DB,保證部分可用,其余的請(qǐng)求返回?cái)嗦菲鞯哪J(rèn)值。
2. 什么是緩存穿透?怎么解決?
解釋 1:緩存查詢一個(gè)沒有的 key,同時(shí)數(shù)據(jù)庫也沒有,如果黑客大量的使用這種方式,那么就會(huì)導(dǎo)致 DB 宕機(jī)。
解決方案:我們可以使用一個(gè)默認(rèn)值來防止,例如,當(dāng)訪問一個(gè)不存在的 key,然后再去訪問數(shù)據(jù)庫,還是沒有,那么就在緩存里放一個(gè)占位符,下次來的時(shí)候,檢查這個(gè)占位符,如果發(fā)生時(shí)占位符,就不去數(shù)據(jù)庫查詢了,防止 DB 宕機(jī)。
解釋 2:大量請(qǐng)求查詢一個(gè)剛剛失效的 key,導(dǎo)致 DB 壓力倍增,可能導(dǎo)致宕機(jī),但實(shí)際上,查詢的都是相同的數(shù)據(jù)。
解決方案:可以在這些請(qǐng)求代碼加上雙重檢查鎖。但是那個(gè)階段的請(qǐng)求會(huì)變慢。不過總比 DB 宕機(jī)好。
3. 什么是緩存并發(fā)競(jìng)爭(zhēng)?怎么解決?
解釋:多個(gè)客戶端寫一個(gè) key,如果順序錯(cuò)了,數(shù)據(jù)就不對(duì)了。但是順序我們無法控制。
解決方案:使用分布式鎖,例如 zk,同時(shí)加入數(shù)據(jù)的時(shí)間戳。同一時(shí)刻,只有搶到鎖的客戶端才能寫入,同時(shí),寫入時(shí),比較當(dāng)前數(shù)據(jù)的時(shí)間戳和緩存中數(shù)據(jù)的時(shí)間戳。
4.什么是緩存和數(shù)據(jù)庫雙寫不一致?怎么解決?
解釋:連續(xù)寫數(shù)據(jù)庫和緩存,但是操作期間,出現(xiàn)并發(fā)了,數(shù)據(jù)不一致了。
通常,更新緩存和數(shù)據(jù)庫有以下幾種順序:
- 先更新數(shù)據(jù)庫,再更新緩存。
- 先刪緩存,再更新數(shù)據(jù)庫。
- 先更新數(shù)據(jù)庫,再刪除緩存。
三種方式的優(yōu)劣來看一下:
先更新數(shù)據(jù)庫,再更新緩存。
這么做的問題是:當(dāng)有 2 個(gè)請(qǐng)求同時(shí)更新數(shù)據(jù),那么如果不使用分布式鎖,將無法控制最后緩存的值到底是多少。也就是并發(fā)寫的時(shí)候有問題。
先刪緩存,再更新數(shù)據(jù)庫。
這么做的問題:如果在刪除緩存后,有客戶端讀數(shù)據(jù),將可能讀到舊數(shù)據(jù),并有可能設(shè)置到緩存中,導(dǎo)致緩存中的數(shù)據(jù)一直是老數(shù)據(jù)。
有 2 種解決方案:
- 使用“雙刪”,即刪更刪,最后一步的刪除作為異步操作,就是防止有客戶端讀取的時(shí)候設(shè)置了舊值。
- 使用隊(duì)列,當(dāng)這個(gè) key 不存在時(shí),將其放入隊(duì)列,串行執(zhí)行,必須等到更新數(shù)據(jù)庫完畢才能讀取數(shù)據(jù)。
總的來講,比較麻煩。
先更新數(shù)據(jù)庫,再刪除緩存
這個(gè)實(shí)際是常用的方案,但是有很多人不知道,這里介紹一下,這個(gè)叫 Cache Aside Pattern,老外發(fā)明的。如果先更新數(shù)據(jù)庫,再刪除緩存,那么就會(huì)出現(xiàn)更新數(shù)據(jù)庫之前有瞬間數(shù)據(jù)不是很及時(shí)。
同時(shí),如果在更新之前,緩存剛好失效了,讀客戶端有可能讀到舊值,然后在寫客戶端刪除結(jié)束后再次設(shè)置了舊值,非常巧合的情況。
有 2 個(gè)前提條件:緩存在寫之前的時(shí)候失效,同時(shí),在寫客戶度刪除操作結(jié)束后,放置舊數(shù)據(jù) —— 也就是讀比寫慢。設(shè)置有的寫操作還會(huì)鎖表。
所以,這個(gè)很難出現(xiàn),但是如果出現(xiàn)了怎么辦?使用雙刪!??!記錄更新期間有沒有客戶端讀數(shù)據(jù)庫,如果有,在更新完數(shù)據(jù)庫之后,執(zhí)行延遲刪除。
還有一種可能,如果執(zhí)行更新數(shù)據(jù)庫,準(zhǔn)備執(zhí)行刪除緩存時(shí),服務(wù)掛了,執(zhí)行刪除失敗怎么辦???
這就坑了!??!不過可以通過訂閱數(shù)據(jù)庫的 binlog 來刪除。