在實(shí)際的業(yè)務(wù)場(chǎng)景中眉枕，我們經(jīng)常會(huì)用 MySQL 存儲(chǔ)數(shù)據(jù)恐疲，隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)量也會(huì)越來越大箩兽，這樣數(shù)據(jù)庫(kù)操作的 I/O 效率會(huì)越來越差撞反、耗時(shí)，影響性能以及用戶體驗(yàn)许师。而且大多數(shù)的用戶請(qǐng)求都是查詢操作搭幻，還可能出現(xiàn)大量重復(fù)的查詢請(qǐng)求俯逾，比如 618 查詢熱門商品等桌肴。

本著緩解 MySQL 數(shù)據(jù)庫(kù)壓力灼捂，提高用戶用戶體驗(yàn)的初衷的猛，我們一般會(huì)考慮使用 Redis 來配合 MySQL署浩，Redis 將數(shù)據(jù)放在內(nèi)存中，查詢效率極高渣磷。將一些查詢頻率高的數(shù)據(jù)緩存到 Redis，這樣用戶的查詢請(qǐng)求過來后授瘦，先去 Redis 中看有沒有數(shù)據(jù)醋界，沒有的話再去 MySQL 查詢。

雖然加入 Redis 可以在一定程度上解決問題提完，但是也產(chǎn)生了一些新的問題形纺，需要注意！

一徒欣、緩存過期策略

我們知道 Redis 會(huì)將數(shù)據(jù)放在內(nèi)存中逐样，但內(nèi)存資源畢竟是有限的，不可能無限制的存儲(chǔ)打肝，要不然內(nèi)存遲早會(huì)爆掉脂新。

這就要用到了 Redis 的緩存過期策略了，給 key 設(shè)置過期時(shí)間粗梭，設(shè)置了過期時(shí)間的 key 會(huì)被存儲(chǔ)到一個(gè)字典中争便，根據(jù)不同的策略，在達(dá)到過期時(shí)間后最終被刪除掉断医。

• 定時(shí)刪除滞乙，Redis 默認(rèn)每100ms 從字典中隨機(jī)取出 20 個(gè) key，并刪除掉其中過期的鉴嗤，如果本次刪除的 key 數(shù)量大于 25% 則再取出 20 個(gè)斩启，以此類推，但每次刪除時(shí)間不超過25ms醉锅，防止持續(xù)的刪除影響性能兔簇。
• 惰性刪除，在定時(shí)刪除策略中，有些 key 可能已經(jīng)過期男韧，但未被選中朴摊，還一直占據(jù)內(nèi)存。此時(shí)就用到了惰性刪除策略此虑，當(dāng)客戶端查詢 key 時(shí)甚纲，如果發(fā)現(xiàn) key 已過期則直接刪除掉。

但是有些 key 可能運(yùn)氣比較好朦前，雖然已經(jīng)過期介杆，但是逃過了上邊兩種刪除策略，繼續(xù)占用內(nèi)存韭寸〈荷冢可能還有一些 key 設(shè)置的過期時(shí)間超長(zhǎng)，還沒過期內(nèi)存就快爆滿了恩伺。所以緩存過期策略還是有一定的局限性赴背，需要緩存淘汰策略來彌補(bǔ)它的局限性。

二晶渠、緩存淘汰策略

當(dāng) Redis 內(nèi)存不足時(shí)凰荚，可以通過配置一些緩存淘汰策略，來應(yīng)對(duì)內(nèi)存不足的問題褒脯。在配置文件中使用maxmemory-policy來設(shè)置不同的策略便瑟。

先來看一下都有哪些策略：

• noeviction，默認(rèn)的策略番川，服務(wù)器不會(huì)主動(dòng)刪除 key到涂，客戶端寫的操作會(huì)報(bào)錯(cuò)，讀以及刪除操作可以正常進(jìn)行颁督。
• volatile-lru践啄，使用 LRU 算法，從設(shè)置了過期時(shí)間的 key 中刪除最近最少使用的适篙。
• volatile-ttl往核，從設(shè)置了過期時(shí)間的 key 中刪除剩余存活時(shí)間最少的。
• volatile-random嚷节，從設(shè)置了過期時(shí)間的 key 中隨機(jī)刪除聂儒。
• volatile-lfu，從設(shè)置了過期時(shí)間的 key 中刪除使用頻率最低的硫痰。
• allkeys-lru衩婚，使用 LRU 算法，刪除最近最少使用的 key效斑，無論 key 是否設(shè)置了過期時(shí)間非春。
• allkeys-random，從所有的 key 中隨即刪除，無論 key 是否設(shè)置了過期時(shí)間
• allkeys-lfu奇昙、從所有的 key 中刪除使用頻率最低的护侮，無論 key 是否設(shè)置了過期時(shí)間

一般使用volatile-lru或allkeys-lru就可以滿足我們的需求，會(huì)刪除最近最少使用的數(shù)據(jù)储耐，也相對(duì)合理一些羊初。當(dāng)然具體如何選擇淘汰策略還需要根據(jù)你的實(shí)際場(chǎng)景分析。

三什湘、緩存穿透

前邊我們說過长赞，加入了 Redis 緩存后，客戶端查詢數(shù)據(jù)時(shí)闽撤，先去 Redis 中看有沒有得哆，沒有的話再去 MySQL 查詢。但是哟旗，如果客戶端請(qǐng)求要查詢的數(shù)據(jù)贩据，在 Redis 緩存中沒有，在 MySQL 中也沒有闸餐，這樣 Redis 緩存將形同虛設(shè)乐设，MySQL 也要做無用的查詢操作，這就是緩存穿透绎巨。

如果有大量的請(qǐng)求都是查詢一些根本不存在的數(shù)據(jù)，會(huì)給數(shù)據(jù)庫(kù)造成一定的壓力蠕啄，如果這些請(qǐng)求是攻擊场勤，可能把數(shù)據(jù)庫(kù)都搞掛了，所以有必要在處理查詢請(qǐng)求前歼跟，先判斷要查詢的數(shù)據(jù)是否存在和媳，不存在就直接返回結(jié)果，不要讓數(shù)據(jù)庫(kù)做無用功哈街。

這個(gè)問題可以使用布隆過濾器解決留瞳，布隆過濾器非常適合在大量的數(shù)據(jù)中判斷指定數(shù)據(jù)是否存在，如果結(jié)果是不存在那就肯定不存在骚秦，但如果結(jié)果是存在就不能保證一定存在了她倘。

所以，可以把查詢相關(guān)的關(guān)鍵數(shù)據(jù)預(yù)先放到布隆過濾器中作箍，這樣請(qǐng)求過來了先判斷布隆過濾器中是否有要查詢的數(shù)據(jù)硬梁，如果布隆過濾器中不存在就不要做后續(xù)的查詢操作了，可以過濾掉大量無效的查詢胞得。

三荧止、緩存擊穿、雪崩

如果緩存中某個(gè)數(shù)據(jù)到了過期時(shí)間，被刪除掉了跃巡，不巧隨后又有大量的請(qǐng)求都是針對(duì)該數(shù)據(jù)的查詢危号，此時(shí)緩存就起不到作用了，所有的請(qǐng)求都需要 MySQL 處理素邪，造成 MySQL 瞬間壓力山大外莲，這種現(xiàn)象就是緩存擊穿。

上邊只是某一個(gè)數(shù)據(jù)過期了娘香，如果緩存中大批量數(shù)據(jù)過期被刪了苍狰，更不巧的是隨后又過來了大量針對(duì)這些過期數(shù)據(jù)的查詢，MySQL 可能扛不住壓力烘绽，就掛掉了淋昭， 這就是緩存雪崩，像是升級(jí)版的緩存擊穿安接。

下邊是解決緩存擊穿翔忽、雪崩的一些方案：

• 可能給 key 設(shè)置過期時(shí)間時(shí)，再額外增加一些隨機(jī)時(shí)間盏檐，避免同一時(shí)間大量緩存數(shù)據(jù)過期
• 設(shè)置一些熱點(diǎn)數(shù)據(jù)不過期歇式，但 MySQL 中對(duì)應(yīng)的數(shù)據(jù)更新、刪除時(shí)需要同步處理緩存中的數(shù)據(jù)
• 限流胡野，避免同一時(shí)間大量查詢請(qǐng)求來到 MySQL