看到好些人在寫更新快取數據代碼時，先刪除快取，然後再更新資料庫，而後續的操作會把數據再裝載的快取中。然而，這個邏輯是錯誤的。試想，兩個並發操作，一個是更新操作，另一個是查詢操作，更新操作刪除快取後，查詢操作沒有命中快取，先把舊數據讀出來後放到快取中，然後更新操作更新了資料庫。於是，在快取中的數據還是舊的數據，導致快取中的數據是髒的，而且還一直這樣髒下去了。
我不知道為什麼這麼多人用的都是這個邏輯，當我在微博上發了這個貼以後，我發現好些人給了好多非常複雜和詭異的方案，所以，我想寫這篇文章說一下幾個快取更新的 Design Pattern（讓我們多一些套路吧）。
這裡，我們先不討論更新快取和更新數據這兩個事是一個事務的事，或是會有失敗的可能，我們先假設更新資料庫和更新快取都可以成功的情況（我們先把成功的代碼邏輯先寫對）。
更新快取的 Design Pattern 有四種：Cache aside, 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 back 還可以合併對同一個數據的多次操作，所以性能的提高是相當可觀的。
但是，其帶來的問題是，數據不是強一致性的，而且可能會丟失（我們知道 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 這樣的強一致性的玩法會導致性能下降。