緩存ABC

緩存ABC

Intro

緩存是一種比較常見的用來將提升系統性能的方式。從線程緩存、進程緩存、到內存緩存再到分佈式緩存再到CDN，都是屬於緩存的範疇。

緩存的本質是空間換時間以提升讀的效率，犧牲一些內存空間來換取以後的快速讀取與訪問。

緩存3問

爲何須要緩存？

通常在項目中，最消耗性能的地方就是後端服務了，然後端的數據庫的讀寫頻率經常都是不均勻分佈的，並且大多狀況是讀多寫少，而且讀操做（select）還會有一些複雜的判斷條件，好比 like、group、join 等等，這些語法是很是消耗性能的，全部會出現不少的慢查詢，所以業務量上來以後，數據庫很容易在讀操做的環節遇到瓶頸。

添加了緩存以後，針對絕大多數的讀多寫少的業務來講可以很大程度上提升業務的qps、提升系統的反應速度，提高用戶的用戶體驗。

使用緩存會遇到哪些問題呢？

1. 數據一致性問題

雖然緩存能夠提升總體性能，可是它也可能會帶來別的問題。例如使用緩存以後，就至關於把數據存放了2份，一份是在數據庫中，另外一份存放在緩存中。當有新的數據要寫入或者舊數據須要更新的時候，若是咱們只更新了其中一份數據源，那兩邊的數據就不一致了，這裏就涉及到使用緩存的一個原則，若是數據有很強的一致性要求就要慎重考慮是否適合使用緩存了。

1. 緩存過時時間問題

   設計緩存的過時時間必須與業務實際狀況相結合。由於若是設計的過時時間過短了，那會致使緩存效果不佳，仍會形成頻繁的從數據庫中往緩存裏寫數據。若是緩存設計的過時時間過長又會致使內存空間的浪費。

2. 緩存的命中率問題

   這也是設計緩存中須要存放哪些數據的很重要一點，若是緩存命中率太低，就會失去緩存效果。通常對於熱點數據而言，要保證命中率達到70%以上效果最佳。

3. 緩存的擊穿/穿透/雪崩問題

• 緩存擊穿

通常的緩存系統，都是按照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

• https://github.com/WeihanLi/WeihanLi.Redis/issues/2
• https://www.cnblogs.com/jsjwk/p/9492777.html

Contact

contact me:weihanli@outlook.com