看到好些人在寫更新緩存資料代碼時，先删除緩存，然後再更新資料庫，而後續的操作會把資料再裝載的緩存中。然而，這個是邏輯是錯誤的。試想，兩個并發操作，一個是更新操作，另一個是查詢操作，更新操作删除緩存後，查詢操作沒有命中緩存，先把老資料讀出來後放到緩存中，然後更新操作更新了資料庫。于是，在緩存中的資料還是老的資料，導緻緩存中的資料是髒的，而且還一直這樣髒下去了。
我不知道為什麼這麼多人用的都是這個邏輯，當我在微網誌上發了這個帖以後，我發現好些人給了好多非常複雜和詭異的方案，是以，我想寫這篇文章說一下幾個緩存更新的design pattern（讓我們多一些套路吧）。
這裡，我們先不讨論更新緩存和更新資料這兩個事是一個事務的事，或是會有失敗的可能，我們先假設更新資料庫和更新緩存都可以成功的情況（我們先把成功的代碼邏輯先寫對）。
更新緩存的的design pattern有四種：cache aside，read through，write through，write behind caching，我們下面一一來看一下這四種pattern。
cache aside pattern
這是最常用的pattern了。其具體邏輯如下：
失效：應用程式先從cache取資料，沒有得到，則從資料庫中取資料，成功後，放到緩存中。
命中：應用程式從cache中取資料，取到後傳回。
更新：先把資料存到資料庫中，成功後，再讓緩存失效。
注意，我們的更新是先更新資料庫，成功後，讓緩存失效。那麼，這種方式是否可以沒有文章前面提到過的那個問題呢？我們可以腦補一下。
一個是查詢操作，一個是更新操作的并發，首先，沒有了删除cache資料的操作了，而是先更新了資料庫中的資料，此時，緩存依然有效，是以，并發的查詢操作拿的是沒有更新的資料，但是，更新操作馬上讓緩存的失效了，後續的查詢操作再把資料從資料庫中拉出來。而不會像文章開頭的那個邏輯産生的問題，後續的查詢操作一直都在取老的資料。
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這樣的強一緻性的玩法會導緻性能下降。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-08-02</b>