大型高并發的后端服務系統，處理瓶頸往往是數據庫，比如mysql的查詢寫入。

為了能夠快速響應用戶請求，系統優化自然會想到利用緩存加快處理速度，常用的比如redis，性能非常高的緩存數據庫。redis搭配mysql一起使用，絕配。

但，沒有免費的午餐，你要用緩存，就不得不面對緩存和數據庫不一致的問題，解決這種不一致有通用設計模式（其實不僅僅是數據庫上的應用），陳皓這篇文章講的比較全面。

以下是原文，侵刪：

看到好些人在寫更新緩存數據代碼時，先刪除緩存，然后再更新數據庫，而后續的讀操作會把數據再裝載的緩存中。然而，這個是邏輯是錯誤的。試想，兩個并發操作，一個是更新操作，另一個是查詢操作，更新操作刪除緩存后，查詢操作沒有命中緩存，先把老數據讀出來后放到緩存中，然后更新操作更新了數據庫。于是，在緩存中的數據還是老的數據，導致緩存中的數據是臟的，而且還一直這樣臟下去了。

我不知道為什么這么多人用的都是這個邏輯，當我在微博上發了這個貼以后，我發現好些人給了好多非常復雜和詭異的方案，所以，我想寫這篇文章說一下幾個緩存更新的Design Pattern（讓我們多一些套路吧）。

這里，我們先不討論更新緩存和更新數據這兩個事是一個事務的事，或是會有失敗的可能，我們先假設更新數據庫和更新緩存都可以成功的情況（我們先把成功的代碼邏輯先寫對）。

更新緩存的的Design Pattern有四種：Cache aside, Read through, Write through, Write behind caching，我們下面一一來看一下這四種Pattern。

Cache Aside Pattern

這是最常用最常用的pattern了。其具體邏輯如下：

失效：應用程序先從cache取數據，沒有得到，則從數據庫中取數據，成功后，放到緩存中。命中：應用程序從cache中取數據，取到后返回。更新：先把數據存到數據庫中，成功后，再讓緩存失效。Cache-Aside-Design-Pat

注意，我們的更新是先更新數據庫，成功后，讓緩存失效。那么，這種方式是否可以沒有文章前面提到過的那個問題呢？我們可以腦補一下。

一個是查詢操作，一個是更新操作的并發，首先，沒有了刪除cache數據的操作了，而是先更新了數據庫中的數據，此時，緩存依然有效，所以，并發的查詢操作拿的是沒有更新的數據，但是，更新操作馬上讓緩存的失效了，后續的查詢操作再把數據從數據庫中拉出來。而不會像文章開頭的那個邏輯產生的問題，后續的查詢操作一直都在取老的數據。

這是標準的design pattern，包括Facebook的論文《Scaling Memcache at Facebook》也使用了這個策略。為什么不是寫完數據庫后更新緩存？你可以看一下Quora上的這個問答《Why does Facebook use delete to remove the key-value pair in Memcached instead of updating the Memcached during write request to the backend?》，主要是怕兩個并發的寫操作導致臟數據。

那么，是不是Cache Aside這個就不會有并發問題了？不是的，比如，一個是讀操作，但是沒有命中緩存，然后就到數據庫中取數據，此時來了一個寫操作，寫完數據庫后，讓緩存失效，然后，之前的那個讀操作再把老的數據放進去，所以，會造成臟數據。

但，這個case理論上會出現，不過，實際上出現的概率可能非常低，因為這個條件需要發生在讀緩存時緩存失效，而且并發著有一個寫操作。而實際上數據庫的寫操作會比讀操作慢得多，而且還要鎖表，而讀操作必需在寫操作前進入數據庫操作，而又要晚于寫操作更新緩存，所有的這些條件都具備的概率基本并不大。

所以，這也就是Quora上的那個答案里說的，要么通過2PC或是Paxos協議保證一致性，要么就是拼命的降低并發時臟數據的概率，而Facebook使用了這個降低概率的玩法，因為2PC太慢，而Paxos太復雜。當然，最好還是為緩存設置上過期時間。

Read/Write Through Pattern

我們可以看到，在上面的Cache Aside套路中，我們的應用代碼需要維護兩個數據存儲，一個是緩存（Cache），一個是數據庫（Repository）。所以，應用程序比較啰嗦。而Read/Write Through套路是把更新數據庫（Repository）的操作由緩存自己代理了，所以，對于應用層來說，就簡單很多了。可以理解為，應用認為后端就是一個單一的存儲，而存儲自己維護自己的Cache。

Read Through

Read Through 套路就是在查詢操作中更新緩存，也就是說，當緩存失效的時候（過期或LRU換出），Cache Aside是由調用方負責把數據加載入緩存，而Read Through則用緩存服務自己來加載，從而對應用方是透明的。

Write Through

Write Through 套路和Read Through相仿，不過是在更新數據時發生。當有數據更新的時候，如果沒有命中緩存，直接更新數據庫，然后返回。如果命中了緩存，則更新緩存，然后再由Cache自己更新數據庫（這是一個同步操作）

下圖自來Wikipedia的Cache詞條。其中的Memory你可以理解為就是我們例子里的數據庫。

Write Behind Caching Pattern

Write Behind 又叫 Write Back。一些了解Linux操作系統內核的同學對write back應該非常熟悉，這不就是Linux文件系統的Page Cache的算法嗎？是的，你看基礎這玩意全都是相通的。所以，基礎很重要，我已經不是一次說過基礎很重要這事了。

Write Back套路，一句說就是，在更新數據的時候，只更新緩存，不更新數據庫，而我們的緩存會異步地批量更新數據庫。這個設計的好處就是讓數據的I/O操作飛快無比（因為直接操作內存嘛 ），因為異步，write backg還可以合并對同一個數據的多次操作，所以性能的提高是相當可觀的。

但是，其帶來的問題是，數據不是強一致性的，而且可能會丟失（我們知道Unix/Linux非正常關機會導致數據丟失，就是因為這個事）。在軟件設計上，我們基本上不可能做出一個沒有缺陷的設計，就像算法設計中的時間換空間，空間換時間一個道理，有時候，強一致性和高性能，高可用和高性性是有沖突的。軟件設計從來都是取舍Trade-Off。

另外，Write Back實現邏輯比較復雜，因為他需要track有哪數據是被更新了的，需要刷到持久層上。操作系統的write back會在僅當這個cache需要失效的時候，才會被真正持久起來，比如，內存不夠了，或是進程退出了等情況，這又叫lazy write。

在wikipedia上有一張write back的流程圖，基本邏輯如下：

再多嘮叨一些 1）上面講的這些Design Pattern，其實并不是軟件架構里的mysql數據庫和memcache/redis的更新策略，這些東西都是計算機體系結構里的設計，比如CPU的緩存，硬盤文件系統中的緩存，硬盤上的緩存，數據庫中的緩存。基本上來說，這些緩存更新的設計模式都是非常老古董的，而且歷經長時間考驗的策略，所以這也就是，工程學上所謂的Best Practice，遵從就好了。

2）有時候，我們覺得能做宏觀的系統架構的人一定是很有經驗的，其實，宏觀系統架構中的很多設計都來源于這些微觀的東西。比如，云計算中的很多虛擬化技術的原理，和傳統的虛擬內存不是很像么？Unix下的那些I/O模型，也放大到了架構里的同步異步的模型，還有Unix發明的管道不就是數據流式計算架構嗎？TCP的好些設計也用在不同系統間的通訊中，仔細看看這些微觀層面，你會發現有很多設計都非常精妙……所以，請允許我在這里放句觀點鮮明的話——如果你要做好架構，首先你得把計算機體系結構以及很多老古董的基礎技術吃透了。

3）在軟件開發或設計中，我非常建議在之前先去參考一下已有的設計和思路，看看相應的guideline，best practice或design pattern，吃透了已有的這些東西，再決定是否要重新發明輪子。千萬不要似是而非地，想當然的做軟件設計。

4）上面，我們沒有考慮緩存（Cache）和持久層（Repository）的整體事務的問題。比如，更新Cache成功，更新數據庫失敗了怎么嗎？或是反過來。關于這個事，如果你需要強一致性，你需要使用“兩階段提交協議”——prepare, commit/rollback，比如Java 7 的XAResource，還有MySQL 5.7的 XA Transaction，有些cache也支持XA，比如EhCache。當然，XA這樣的強一致性的玩法會導致性能下降，關于分布式的事務的相關話題，你可以看看《分布式系統的事務處理》一文。

以上，就是陳皓大佬的文章，站在大佬的肩膀上，lemon 也有些思考，作者一開始就提出：

先刪除緩存，然后再更新數據庫，而后續的操作會把數據再裝載的緩存中。然而，這個是邏輯是錯誤的。

隨后提出的 Facebook 采用的Cache Aside Pattern 的最佳實踐，其實本質上是?先更新數據庫，后刪緩存?，雖然有可能出錯，但概率比較低，更能被接受。

暫且不說這個結論對不對，咱們自己對比下，這兩種一致性策略：

? 先更新數據庫，再刪除緩存。就是前面的 Cache aside

? 先刪除緩存，再更新數據庫

有人要問了，為什么都是刪除緩存，而不是更新呢？

因為更新麻煩呀！還容易出錯，不如直接刪除。而且你每次更新完，后面不一定有請求來讀，浪費時間。還不如讓后續讀請求來更新，簡單高效，這和 Linux 進程復制的 copy on write 有異曲同工之妙。

其實，誰好誰壞，選擇哪一個，并沒有那么絕對，兩種策略在并發情況下，都存在不一致的可能。目前工程應用上，對?先刪除緩存，再更新數據庫?有兩個主要優化：

1. 延時雙刪（「緩存刪了又怕被污染，延時再刪一次」）
2. 異步更新緩存（「基于訂閱binlog的同步機制，阿里的canal、騰訊的Mysync，并發緩存更新串行化」）

通過這些措施，?先刪除緩存，再更新數據庫? ，也能滿足業務的一致性要求，所以，沒有完美的解決方案，只有適合業務場景，最終選擇哪個，是在一致性和性能之間的Trade-Off，或者，老板說哪個好，我就用哪個。