本文內容參考網路，侵刪

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視
> https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章首發於我的個人部落格：
> www.how2playlife.com

該系列博文會告訴你什麼是分散式系統，這對後端工程師來說是很重要的一門學問，我們會逐步瞭解常見的分散式技術、以及一些較為常見的分散式系統概念，同時也需要進一步瞭解zookeeper、分散式事務、分散式鎖、負載均衡等技術，以便讓你更完整地瞭解分散式技術的具體實戰方法，為真正應用分散式技術做好準備。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

本文轉載自 linkedkeeper.com

# 快取更新的套路

看到好些人在寫更新快取資料程式碼時，**先刪除快取，然後再更新資料庫**，而後續的操作會把資料再裝載的快取中。**然而，這個是邏輯是錯誤的**。試想，兩個併發操作，一個是更新操作，另一個是查詢操作，更新操作刪除快取後，查詢操作沒有命中快取，先把老資料讀出來後放到快取中，然後更新操作更新了資料庫。於是，在快取中的資料還是老的資料，導致快取中的資料是髒的，而且還一直這樣髒下去了。

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

這裡，我們先不討論更新快取和更新資料這兩個事是一個事務的事，或是會有失敗的可能，我們先假設更新資料庫和更新快取都可以成功的情況（我們先把成功的程式碼邏輯先寫對）。

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

#### Cache Aside Pattern

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

*   **失效**：應用程式先從cache取資料，沒有得到，則從資料庫中取資料，成功後，放到快取中。

*   **命中**：應用程式從cache中取資料，取到後返回。

*   **更新**：先把資料存到資料庫中，成功後，再讓快取失效。

![Cache-Aside-Design-Pattern-Flow-Diagram](https://coolshell.cn/wp-content/uploads/2016/07/Cache-Aside-Design-Pattern-Flow-Diagram-e1470471723210.png)

![Updating-Data-using-the-Cache-Aside-Pattern-Flow-Diagram-1](https://coolshell.cn/wp-content/uploads/2016/07/Updating-Data-using-the-Cache-Aside-Pattern-Flow-Diagram-1-e1470471761402.png)

注意，我們的更新是先更新資料庫，成功後，讓快取失效。那麼，這種方式是否可以沒有文章前面提到過的那個問題呢？我們可以腦補一下。

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

這是標準的design pattern，包括Facebook的論文《[Scaling Memcache at Facebook](https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf)》也使用了這個策略。為什麼不是寫完資料庫後更新快取？你可以看一下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?](https://www.quora.com/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詞條](https://en.wikipedia.org/wiki/Cache_(computing))。其中的Memory你可以理解為就是我們例子裡的資料庫。

![Write-through_with_no-write-allocation](https://coolshell.cn/wp-content/uploads/2016/07/460px-Write-through_with_no-write-allocation.svg_.png)

#### 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的流程圖，基本邏輯如下：

![Write-back_with_write-allocation](https://coolshell.cn/wp-content/uploads/2016/07/Write-back_with_write-allocation.png)

#### 再多嘮叨一些

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](http://docs.oracle.com/javaee/7/api/javax/transaction/xa/XAResource.html)，還有MySQL 5.7的 [XA Transaction](http://dev.mysql.com/doc/refman/5.7/en/xa.html)，有些cache也支援XA，比如[EhCache](http://www.ehcache.org/documentation/3.0/xa.html)。當然，XA這樣的強一致性的玩法會導致效能下降，關於分散式的事務的相關話題，你可以看看《[分散式系統的事務處理](https://coolshell.cn/articles/10910.html)》一文。

（全文完）

搞懂分散式技術15：快取更新的套路

相關文章