NO IMAGE
1 Star2 Stars3 Stars4 Stars5 Stars 給文章打分!
Loading...

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

我不知道為什麼這麼多人用的都是這個邏輯,當我在微博上發了這個貼以後,我發現好些人給了好多非常複雜和詭異的方案,所以,我想寫這篇文章說一下幾個快取更新的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-through_with_no-write-allocation

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

 

再多嘮叨一些

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這樣的強一致性的玩法會導致效能下降,關於分散式的事務的相關話題,你可以看看《分散式系統的事務處理》一文。

(全文完)

轉自:http://coolshell.cn/articles/17416.html

相關文章

程式語言 最新文章