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

看到這里可能有些朋友會內心肯定會淡淡的說上一句：寫操作先更新 DB，然后在更新緩存，讀操作先讀緩存，如果沒有讀 DB 回種緩存，然后返回結果不就完事了么，這有什么好講的？

只要你有這樣的疑問，那么請你一定認真看完本文，因為緩存讀寫策略遠不止你想的那么簡單，下面我們就來分析一下幾種常用的緩存讀寫方案，看看哪種更適合你。

讀寫緩存策略一

如上圖所示，對于寫操作，先寫 DB，如果 DB 成功，則同步寫入緩存；對于讀操作，首先從緩存中讀取，若緩存未命中，則從 DB 中獲取，如果取到了結果，將結果回種緩存并返回，若 DB 中也沒有結果，則在緩存中設置一個短暫帶有過期時間的空值，防止相同 key 頻繁請求對 DB 造成大量的無效請求。

策略一優(yōu)缺點對比

• 優(yōu)點

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

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

Cache Aside 讀寫策略

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

• 讀流程：

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

1. 首先將將結果寫入 DB
2. 然后刪除緩存中對應的值

實際生產環(huán)境中，此種策略的使用也相對比較廣泛，可以作為一種參考。這里需要注意一點的是，針對寫流程，不能先刪除緩存，在更新 DB，因為緩存刪除后，此時 DB 還沒有更新完時，來了一個 get 請求，那么緩存就有可能會被種入一個已失效的結果。

Cache Aside 讀寫策略優(yōu)缺點對比

• 優(yōu)點：

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

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

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

對于增加過期時間的這種方式，存在極熱 key 的場景并不是適用的，因為一旦 key 過期后，在一瞬間大量請求越過緩存，直沖 DB，也就造成了緩存穿透的問題，所以 Cache Aside 方案看起來很不錯，但是也不是萬能的。

Write/Read Through 策略

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

• 讀流程：

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

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

Write/Read Through 策略優(yōu)缺點對比

• 優(yōu)點：

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

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

總和上面這些情況對比，目前采用此種緩存讀寫策略的場景很少，作者到目前還沒有見過使用這種緩存策略的場景。

Write Back 策略

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

• 寫操作流程如下：

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

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

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

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

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

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

總結

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

特別推薦一個分享架構+算法的優(yōu)質內容，還沒關注的小伙伴，可以長按關注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝