北京快乐8官网|北京快乐8选一秘诀

品略圖書館

別再犯低級錯誤,帶你了解更新緩存的四種Desigh Pattern

在我們使用分布式緩存Redis或者Memcached編寫更新緩存數據代碼時,我們總是會犯一個邏輯錯誤。先刪除緩存,然后再更新數據庫,而后續的操作會把數據再裝載的緩存中。試想,兩個并發操作,一個是更新操作,另一個是查詢操作,更新操作刪除緩存后,查詢操作沒有命中緩存,先把老數據讀出來后放到緩存中,然后更新操作更新了數據庫。于是,在緩存中的數據還是老的數據,導致緩存中的數據是臟的,而且還一直這樣臟下去了。

我不知道為什么這么多人用的都是這個邏輯,所以,我想寫這篇文章說一下幾個緩存更新的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。

1.Read Through

Read Through 套路就是在查詢操作中更新緩存,也就是說,當緩存失效的時候(過期或LRU換出),Cache Aside是由調用方負責把數據加載入緩存,而Read Through則用緩存服務自己來加載,從而對應用方是透明的。

2.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的流程圖,基本邏輯如下:

基本上來說,這些緩存更新的設計模式都是非常老古董的,而且歷經長時間考驗的策略,所以這也就是,工程學上所謂的Best Practice,遵從就好了。

另外,請允許我在這里放句觀點鮮明的話——如果你要做好架構,首先你得把計算機體系結構以及很多老古董的基礎技術吃透了。

所以,在軟件開發或設計中,我非常建議在之前先去參考一下已有的設計和思路,看看相應的guideline,best practice或design pattern,吃透了已有的這些東西,再決定是否要重新發明輪子。千萬不要似是而非地,想當然的做軟件設計。

免責聲明:本文僅代表文章作者的個人觀點,與本站無關。其原創性、真實性以及文中陳述文字和內容未經本站證實,對本文以及其中全部或者部分內容文字的真實性、完整性和原創性本站不作任何保證或承諾,請讀者僅作參考,并自行核實相關內容。

http://www.kzguv.com.cn/style/images/nopic.gif
我要收藏
個贊
被踩
分享到
分享
評論
首頁
北京快乐8官网