緩存ABC Intro 緩存是一種比較常見的用來將提高系統性能的方式。從線程緩存、進程緩存、到記憶體緩存再到分散式緩存再到CDN，都是屬於緩存的範疇。 緩存的本質是 以提高讀的效率，犧牲一些記憶體空間來換取之後的快速讀取與訪問。 緩存3問 為什麼需要緩存？ 一般在項目中，最消耗性能的地方就是後端服務了， ...
緩存ABC
Intro
緩存是一種比較常見的用來將提高系統性能的方式。從線程緩存、進程緩存、到記憶體緩存再到分散式緩存再到CDN，都是屬於緩存的範疇。
緩存的本質是空間換時間以提高讀的效率，犧牲一些記憶體空間來換取之後的快速讀取與訪問。
緩存3問
為什麼需要緩存？
一般在項目中，最消耗性能的地方就是後端服務了，而後端的資料庫的讀寫頻率常常都是不均勻分佈的，而且大多情況是讀多寫少，並且讀操作（select）還會有一些複雜的判斷條件，比如 like、group、join 等等，這些語法是非常消耗性能的，所有會出現很多的慢查詢，因此業務量上來之後，資料庫很容易在讀操作的環節遇到瓶頸。
添加了緩存之後，針對絕大多數的讀多寫少的業務來說能夠很大程度上提高業務的qps、提高系統的反應速度，提升用戶的用戶體驗。
使用緩存會遇到哪些問題呢？
- 數據一致性問題
雖然緩存可以提高整體性能，但是它也可能會帶來別的問題。例如使用緩存之後，就相當於把數據存放了2份，一份是在資料庫中，另一份存放在緩存中。當有新的數據要寫入或者舊數據需要更新的時候，如果我們只更新了其中一份數據源，那兩邊的數據就不一致了，這裡就涉及到使用緩存的一個原則，如果數據有很強的一致性要求就要慎重考慮是否適合使用緩存了。
緩存過期時間問題
設計緩存的過期時間必須與業務實際情況相結合。因為如果設計的過期時間太短了，那會導致緩存效果不佳，仍會造成頻繁的從資料庫中往緩存里寫數據。如果緩存設計的過期時間過長又會導致記憶體空間的浪費。
緩存的命中率問題
這也是設計緩存中需要存放哪些數據的很重要一點，如果緩存命中率過低，就會失去緩存效果。一般對於熱點數據而言，要保證命中率達到70%以上效果最佳。
緩存的擊穿/穿透/雪崩問題
- 緩存擊穿
一般的緩存系統，都是按照key去緩存查詢，如果不存在對應的value，就應該去後端系統查找（比如db）。如果key對應的value是一定不存在的，並且對該key併發請求量很大，就會對後端系統造成很大的壓力。在高併發下,多線程同時查詢同一個資源,如果緩存中沒有這個資源,那麼這些線程都會去資料庫查找,對資料庫造成極大壓力,緩存失去存在的意義
- 緩存雪崩
當緩存伺服器重啟或者大量緩存集中在某一個時間段失效，這樣在失效的時候，也會給後端系統(比如db)帶來很大壓力。
- 緩存穿透
緩存穿透是指用戶查詢數據，在資料庫沒有，自然在緩存中也不會有。這樣就導致用戶查詢的時候，在緩存中找不到，每次都要去資料庫中查詢。
什麼樣的情景下使用緩存
- 讀多寫少的業務場景
- 對數據一致性性要求不高，允許一定時間內的數據不一致
- 允許緩存丟失，使用緩存要考慮緩存miss的處理
緩存的更新策略具體有哪些？
典型的緩存模式，一般有如下幾種：
Cache Aside
Read/Write Through
Write Behind
每種模式都有不同的特點，適應與不同的項目場景，下麵來依次看看：
Cache Aside 模式
這是大家經常用到的一種策略模式。這種模式主要流程如下：
應用在查詢數據的時候，先從緩存Cache中讀取數據，如果緩存中沒有，則再從資料庫中讀取數據，得到資料庫的數據之後，將這個數據也放到緩存Cache中。
如果應用要更新某個數據，也是先去更新資料庫中的數據，更新完成之後，則通過指令讓緩存Cache中的數據失效。
這裡為什麼不讓更新操作在寫完資料庫之後，緊接著去把緩存Cache中的數據也修改了呢？
主要是因為這樣做的話，就有2個寫操作的事件了，擔心在併發的情況下會導致臟數據，舉個例子：
假如同時有2個請求，請求A和請求B，併發的執行。請求A是要去讀數據，請求B是要去更新數據。初始狀態緩存中是沒有數據的，當請求A讀到數據之後，準備往回寫的時候，此刻，請求B正好要更新數據，更新完了資料庫之後，又去把緩存更新了，那請求A再往緩存中寫的就是舊數據了，屬於臟數據。
那麼 Cache Aside 模式就沒有臟數據問題了嗎？不是的，在極端情況下也可能會產生臟數據，比如：
假如同時有2個請求，請求A和請求B，併發的執行。請求A是要去讀數據，請求B是要去寫數據。假如初始狀態緩存中沒有這個數據，那請求A發現緩存中沒有數據，就會去資料庫中讀數據，讀到了數據準備寫回緩存中，就在這個時候，請求B是要去寫數據的，請求B在寫完資料庫的數據之後，又去設置了緩存失效。這個時候，請求A由於在資料庫中讀到了之前的舊數據，開始往緩存中寫數據了，此時寫進入的就也是舊數據。那麼最終就會導致，緩存中的數據與資料庫的數據不一致，造成了臟數據。
不過這種概率比上面一種概率要小很多。所以整體而言 Cache Aside 模式 還是一種比較簡單實用的方式。
Read/Write Through 模式
這個模式其實就是將 緩存服務 作為主要的存儲，應用的所有讀寫請求都是直接與緩存服務打交道，而不管最後端的資料庫了，資料庫的數據由緩存服務來維護和更新。不過緩存中數據變更的時候是同步去更新資料庫的，在應用的眼中只有緩存服務。
流程就相當簡單了：
應用要讀數據和更新數據都直接訪問緩存服務，緩存服務同步的將數據更新到資料庫
這個模式出現臟數據的概率比較低，但是太依賴緩存服務了，對緩存服務的穩定性有較大要求。
Write Behind 模式
這個模式就是 Read/Write Through 模式 的一個變種。區別就是 Read/Write Through 模式的緩存寫資料庫的時候是同步的，而 Write Behind 模式 的緩存操作資料庫是非同步的。
流程如下：
應用要讀數據和更新數據都直接訪問緩存服務
緩存服務非同步的將數據更新到資料庫（通過非同步任務）
這個模式的特點就是速度很快，效率會非常高，但是數據的一致性比較差，還可能會有數據的丟失情況，實現邏輯也較為複雜。
Reference
Contact
contact me:[email protected]
