緩存服務的更新策略有哪些？
原文:緩存服務的更新策略有哪些？
在互聯網項目開發中，緩存的應用是非常普遍了，緩存可以幫助頁面提高加載速度，減少服務器或數據源的負載。
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模式等由於使用的不是很常見就不詳細介紹了。
緩存是互聯網項目中非常普遍的一個提高效率的方案，用法比較多，也比較關鍵，大家可以一起交流。
緩存服務的更新策略有哪些？