原文：https://coolshell.cn/articles/17416.html
看到好些人在寫更新快取資料程式碼時，先刪除快取，然後再更新資料庫，而後續的操作會把資料再裝載的快取中。然而，這個是邏輯是錯誤的。試想，兩個併發操作，一個是更新操作，另一個是查詢操作，更新操作刪除快取後，查詢操作沒有命中快取，先把老資料讀出來後放到快取中，然後更新操作更新了資料庫。於是，在快取中的資料還是老的資料，導致快取中的資料是髒的，而且還一直這樣髒下去了。
我不知道為什麼這麼多人用的都是這個邏輯，當我在微博上發了這個貼以後，我發現好些人給了好多非常複雜和詭異的方案，所以，我想寫這篇文章說一下幾個快取更新的Design Pattern（讓我們多一些套路吧）。
這裡，我們先不討論更新快取和更新資料這兩個事是一個事務的事，或是會有失敗的可能，我們先假設更新資料庫和更新快取都可以成功的情況（我們先把成功的程式碼邏輯先寫對）。
更新快取的的Design Pattern有四種：Cache aside, Read through, Write through, Write behind caching，我們下面一一來看一下這四種Pattern。
目錄
- Cache Aside Pattern
- Read/Write Through Pattern
- Read Through
- Write Through
- Write Behind Caching Pattern
- 再多嘮叨一些
Cache Aside Pattern
這是最常用最常用的pattern了。其具體邏輯如下：
- 失效：應用程式先從cache取資料，沒有得到，則從資料庫中取資料，成功後，放到快取中。
- 命中：應用程式從cache中取資料，取到後返回。
- 更新：先把資料存到資料庫中，成功後，再讓快取失效。
注意，我們的更新是先更新資料庫，成功後，讓快取失效。那麼，這種方式是否可以沒有文章前面提到過的那個問題呢？我們可以腦補一下。
一個是查詢操作，一個是更新操作的併發，首先，沒有了刪除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這樣的強一致性的玩法會導致效能下降，關於分散式的事務的相關話題，你可以看看《分散式系統的事務處理》一文。