怎樣使用主流緩存更新策略來減小性能消耗？

 

在互聯網項目開發中，緩存的應用是很是廣泛了，緩存能夠幫助頁面提升加載速度，減小服務器或數據源的負載。

1、爲何須要緩存？

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

那麼經過在數據庫前面，前置一個緩存服務，就能夠有效的吸取不均勻的請求，抵擋流量波峯。

另外，若是應用與數據源不在同一個服務器，中間還會有不少的網絡消耗，也會對應用的響應速度有很大影響，若是當前應用對數據實時性的要求不那麼強的話，在應用側加上緩存就能很快速地提高效率。

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

雖然緩存能夠提升總體性能，可是它也可能會帶來別的問題。

例如使用緩存以後，就至關於把數據存放了2份，一份是在數據庫中，另外一份存放在緩存中。當有新的數據要寫入或者舊數據須要更新的時候，若是咱們只更新了其中一份數據源，那兩邊的數據就不一致了。因此這裏就存在一個緩存數據與數據庫數據如何進行有效且快速的同步才能夠保證數據最終一致性的問題。

另外，加上緩存服務其實也引入了系統架構的複雜度，由於還須要額外的關注緩存自身帶來的下列問題：

一、緩存的過時時間問題

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

二、緩存的命中率問題

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

三、緩存的穿透/雪崩問題

穿透/雪崩問題是指若是緩存服務一旦宕機或所有丟失，那麼有可能一瞬間全部的流量都直接打到了後端數據庫上，可能會形成連鎖反應，瞬間的請求高峯極有可能致使數據庫沒法承載。

3、緩存的更新策略具體有哪些？

典型的緩存模式，通常有以下幾種：

• 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模式的緩存操做數據庫是異步的。

流程以下：

• 應用要讀數據和更新數據都直接訪問緩存服務；
• 緩存服務異步的將數據更新到數據庫（經過異步任務）。

這個模式的特色就是速度很快，效率會很是高，可是數據的一致性比較差，還可能會有數據丟失的狀況，實現邏輯也較爲複雜。

以上就是目前三種主流的緩存更新策略，另外還有Refrsh-Ahead模式等因爲使用的不是很常見就不詳細介紹了。

順便在此給你們推薦一個Java架構方面的交流學習羣：698581634，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系，主要針對Java開發人員提高本身，突破瓶頸，相信你來學習，會有提高和收穫。在這個羣裏會有你須要的內容  朋友們請抓緊時間加入進來吧。