前面利用 6 篇文章講述了 Redis 相關(guān)的基礎(chǔ)知識(shí)，相信小伙伴們對(duì) Redis 已經(jīng)有了一個(gè)比較深入的認(rèn)識(shí)和理解了；本文來(lái)講講實(shí)際生產(chǎn)環(huán)境中 Redis 作為常用緩存組件是怎么和 DB（關(guān)系型數(shù)據(jù)庫(kù)，比如 MySQL）配合使用的。

看到這里可能有些朋友會(huì)內(nèi)心肯定會(huì)淡淡的說(shuō)上一句：寫(xiě)操作先更新 DB，然后在更新緩存，讀操作先讀緩存，如果沒(méi)有讀 DB 回種緩存，然后返回結(jié)果不就完事了么，這有什么好講的？

只要你有這樣的疑問(wèn)，那么請(qǐng)你一定認(rèn)真看完本文，因?yàn)榫彺?a href="/tags/讀寫(xiě)" target="_blank">讀寫(xiě)策略遠(yuǎn)不止你想的那么簡(jiǎn)單，下面我們就來(lái)分析一下幾種常用的緩存讀寫(xiě)方案，看看哪種更適合你。

讀寫(xiě)緩存策略一

如上圖所示，對(duì)于寫(xiě)操作，先寫(xiě) DB，如果 DB 成功，則同步寫(xiě)入緩存；對(duì)于讀操作，首先從緩存中讀取，若緩存未命中，則從 DB 中獲取，如果取到了結(jié)果，將結(jié)果回種緩存并返回，若 DB 中也沒(méi)有結(jié)果，則在緩存中設(shè)置一個(gè)短暫帶有過(guò)期時(shí)間的空值，防止相同 key 頻繁請(qǐng)求對(duì) DB 造成大量的無(wú)效請(qǐng)求。

策略一優(yōu)缺點(diǎn)對(duì)比

• 優(yōu)點(diǎn)

1. 緩存讀寫(xiě)策略簡(jiǎn)單（在很多讀多寫(xiě)少的場(chǎng)景中，此種策略使用的頻率還是很高的）。
2. 不需要依賴(lài)其他第三方緩存組件協(xié)同完成。

舉個(gè)例子，如上圖所示，假設(shè)兩條線(xiàn)程 1 和線(xiàn)程 2 同時(shí)對(duì)一件特價(jià)商品進(jìn)行價(jià)格調(diào)整，假設(shè)商品初始狀態(tài)為 20 元，線(xiàn)程 1 將其價(jià)格修改為 19 元并寫(xiě)入緩存，然后線(xiàn)程 2 將商品的價(jià)格修改為 18 元，此時(shí)線(xiàn)程 A 進(jìn)行讀取操作，因?yàn)榫€(xiàn)程 2 還沒(méi)來(lái)得及將緩存數(shù)據(jù)修改為 18，所以此時(shí)線(xiàn)程 1 拿到的價(jià)格為 19 元，但是此時(shí)庫(kù)里的價(jià)格卻是 18 元。從這個(gè)例子可以看出，對(duì)于進(jìn)行頻繁修改的數(shù)據(jù)，使用此種緩存讀寫(xiě)策略顯然是不合理的。針對(duì)這種緩存讀寫(xiě)方案的缺陷，我們來(lái)看看下一種緩存讀寫(xiě)策略。

Cache Aside 讀寫(xiě)策略

Cache Aside 讀寫(xiě)策略也叫緩存旁路讀寫(xiě)策略，從上圖可以看出，針對(duì)讀寫(xiě)的策略分別是：

• 讀流程：

1. 首先從緩存中讀取，如果有結(jié)果則直接返回結(jié)束
2. 如果緩存中沒(méi)有，則讀 DB 并將結(jié)果回種緩存，然后返回結(jié)束

1. 首先將將結(jié)果寫(xiě)入 DB
2. 然后刪除緩存中對(duì)應(yīng)的值

實(shí)際生產(chǎn)環(huán)境中，此種策略的使用也相對(duì)比較廣泛，可以作為一種參考。這里需要注意一點(diǎn)的是，針對(duì)寫(xiě)流程，不能先刪除緩存，在更新 DB，因?yàn)榫彺鎰h除后，此時(shí) DB 還沒(méi)有更新完時(shí)，來(lái)了一個(gè) get 請(qǐng)求，那么緩存就有可能會(huì)被種入一個(gè)已失效的結(jié)果。

Cache Aside 讀寫(xiě)策略?xún)?yōu)缺點(diǎn)對(duì)比

• 優(yōu)點(diǎn)：

1. 從流程圖看，此種策略實(shí)現(xiàn)比較簡(jiǎn)單。
2. 對(duì)于緩存和 DB 的一致性有了一定的保證，其可以解決第一種緩存方案遇到的問(wèn)題。

1. 很顯然，每次更新數(shù)據(jù)，都會(huì)先更新 DB 緊接著就刪除緩存，如果讀寫(xiě)操作都比較頻繁的情況下，勢(shì)必使得緩存的命中率有所折扣，也就意味著緩存的 miss 率升高，從而導(dǎo)致在一定程度上削弱了緩存的作用。

針對(duì)此種方案的缺點(diǎn)，其實(shí)也有一些比較折中的方案可以考慮。比如在更新 DB 完成后，同樣更新緩存，但是在更新緩存的時(shí)候增加分布式鎖避免；在比如如果業(yè)務(wù)場(chǎng)景并不是要求強(qiáng)一致性的話(huà)，可以將數(shù)據(jù)寫(xiě)入緩存并增加一個(gè)過(guò)期時(shí)間，這樣即使數(shù)據(jù)不一致也只是一段時(shí)間。

對(duì)于增加過(guò)期時(shí)間的這種方式，存在極熱 key 的場(chǎng)景并不是適用的，因?yàn)橐坏?key 過(guò)期后，在一瞬間大量請(qǐng)求越過(guò)緩存，直沖 DB，也就造成了緩存穿透的問(wèn)題，所以 Cache Aside 方案看起來(lái)很不錯(cuò)，但是也不是萬(wàn)能的。

Write/Read Through 策略

Write/Read Through 的緩存策略不同于前兩種，該策略需要引入第三方緩存同步插件。其讀寫(xiě)流程如下：

• 讀流程：

1. 首先讀緩存，如果緩存命中，則直接返回結(jié)果
2. 如果緩存未命中，則依賴(lài)第三方組件從 DB 中加載數(shù)據(jù)到緩存中，然后將獲取的結(jié)果返回。

1. 要更新的數(shù)據(jù)是否在緩存中存在，若存在則直接將數(shù)據(jù)寫(xiě)入緩存，之后緩存數(shù)據(jù)由第三方緩存組件將其更新到 DB
2. 若緩存中不存在，則直接將結(jié)果寫(xiě)入 DB，這種稱(chēng)之為寫(xiě)穿透

Write/Read Through 策略?xún)?yōu)缺點(diǎn)對(duì)比

• 優(yōu)點(diǎn)：

1. 寫(xiě)緩存 miss 的情況除外，剩余所有操作都只與緩存進(jìn)行交互，很大程度上避免了緩存與 DB 一直性的情況

1. 從上面流程中不難看出，寫(xiě)緩存 miss 時(shí)直接與 DB 交互，會(huì)造成請(qǐng)求耗時(shí)增加
2. 此種緩存策略引入了第三方緩存組件進(jìn)行輔助，從而增加了系統(tǒng)的復(fù)雜度和系統(tǒng)的維護(hù)難度
3. 由于需要引入第三方組件，而目前很多緩存如 Redis 原生并不兼容第三方組件，所以很難引入

總和上面這些情況對(duì)比，目前采用此種緩存讀寫(xiě)策略的場(chǎng)景很少，作者到目前還沒(méi)有見(jiàn)過(guò)使用這種緩存策略的場(chǎng)景。

Write Back 策略

Write Back 策略是一種操作系統(tǒng)在使用的緩存讀寫(xiě)策略，由于其實(shí)現(xiàn)比較復(fù)雜，所以讀者朋友可以做一些了解即可，目前沒(méi)有在生產(chǎn)環(huán)境中實(shí)際使用過(guò)。

• 寫(xiě)操作流程如下：

1. 寫(xiě)請(qǐng)求來(lái)之后，首先判斷要寫(xiě)的 key 在緩存中是否被標(biāo)記為“臟數(shù)據(jù)”，如果不是“臟數(shù)據(jù)”則直接寫(xiě)緩存，然后將其標(biāo)記為臟數(shù)據(jù)
2. 如果緩存中標(biāo)記的是“臟數(shù)據(jù)”，則直接將其寫(xiě)入 DB，然后回種緩存，然后將其標(biāo)記為“臟數(shù)據(jù)”

1. 首先從緩存中獲取數(shù)據(jù)，若有則直接返回
2. 若緩存中沒(méi)有，則尋找可用的緩存快，若緩存快被標(biāo)記為“臟數(shù)據(jù)”，則將“臟數(shù)據(jù)”寫(xiě)入 DB，然后將緩存的數(shù)據(jù)標(biāo)記為“非臟數(shù)據(jù)”，然后返回
3. 若緩存快中的數(shù)據(jù)不是“臟數(shù)據(jù)”，則從 DB 中加載數(shù)據(jù)到緩存中，然后將其返回。

生產(chǎn)環(huán)境中其他的緩存讀寫(xiě)策略

除了上面我們介紹的 4 中緩存讀寫(xiě)策略，實(shí)際生產(chǎn)環(huán)境中還有一些比較常見(jiàn)的策略，比如針對(duì)熱點(diǎn) key 使用的 LRU 緩存策略。

實(shí)際生產(chǎn)中，某些場(chǎng)景數(shù)據(jù)量是非常巨大的，比如微博用戶(hù) uid，方便查看某個(gè)用戶(hù)的最近狀態(tài)，如果全部將其全部都寫(xiě)入到緩存，顯然是不合理的；一是緩存存儲(chǔ)不了那么多用戶(hù)信息，二是對(duì)應(yīng)絕大部分用戶(hù)是完全沒(méi)有必要寫(xiě)入緩存的，因?yàn)閷?duì)于很大一部分用戶(hù)信息，只有很少的訪(fǎng)問(wèn)量。所以對(duì)于這種場(chǎng)景，只需要緩存最近經(jīng)常被訪(fǎng)問(wèn)的那部分用戶(hù)信息即可，針對(duì)這種場(chǎng)景，也就誕生了 LRU 緩存。

其實(shí) LRU 緩存在很多框架中也被廣泛使用，需要的朋友可以自己研究下很簡(jiǎn)單的（這里其實(shí)也有有一道算法題，感興趣的朋友可以自行在 LeetCode 上搜索）

總結(jié)

本文介紹了 5 中生產(chǎn)環(huán)境中經(jīng)常用到的緩存讀寫(xiě)策略，讀者朋友們可以根據(jù)自己的實(shí)際業(yè)務(wù)場(chǎng)景，對(duì)其進(jìn)行適當(dāng)?shù)母脑炀涂梢詰?yīng)用到自己的環(huán)境中了。好了，就講這么多，更多的需要朋友們自行多多體會(huì)和應(yīng)用。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝