看到好些人在寫更新緩存資料代碼時，先删除緩存，然後再更新資料庫，而後續的操作會把資料再裝載的緩存中。然而，這個是邏輯是錯誤的。試想，兩個并發操作，一個是更新操作，另一個是查詢操作，更新操作删除緩存後，查詢操作沒有命中緩存，先把老資料讀出來後放到緩存中，然後更新操作更新了資料庫。于是，在緩存中的資料還是老的資料，導緻緩存中的資料是髒的，而且還一直這樣髒下去了。
我不知道為什麼這麼多人用的都是這個邏輯，當我在微網誌上發了這個貼以後，我發現好些人給了好多非常複雜和詭異的方案，是以，我想寫這篇文章說一下幾個緩存更新的Design Pattern（讓我們多一些套路吧）。
這裡，我們先不讨論更新緩存和更新資料這兩個事是一個事務的事，或是會有失敗的可能，我們先假設更新資料庫和更新緩存都可以成功的情況（我們先把成功的代碼邏輯先寫對）。
更新緩存的的Design Pattern有四種：Cache aside, Read through, Write through, Write behind caching，我們下面一一來看一下這四種Pattern。
Cache Aside Pattern
這是最常用最常用的pattern了。其具體邏輯如下：
1.失效：應用程式先從cache取資料，沒有得到，則從資料庫中取資料，成功後，放到緩存中。
2.命中：應用程式從cache中取資料，取到後傳回。
3.更新：先把資料存到資料庫中，成功後，再讓緩存失效。
注意，我們的更新是先更新資料庫，成功後，讓緩存失效。那麼，這種方式是否可以沒有文章前面提到過的那個問題呢？我們可以腦補一下。
一個是查詢操作，一個是更新操作的并發，首先，沒有了删除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。
1.Read Through
Read Through 套路就是在查詢操作中更新緩存，也就是說，當緩存失效的時候（過期或LRU換出），Cache Aside是由調用方負責把資料加載入緩存，而Read Through則用緩存服務自己來加載，進而對應用方是透明的。
2.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這樣的強一緻性的玩法會導緻性能下降，關于分布式的事務的相關話題，你可以看看《分布式系統的事務處理》一文。