成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

緩存更新的套路是怎樣的?

存儲 存儲軟件
看到好些人在寫更新緩存數據代碼時,先刪除緩存,然后再更新數據庫,而后續的操作會把數據再裝載的緩存中。然而,這個是邏輯是錯誤的。

 看到好些人在寫更新緩存數據代碼時,先刪除緩存,然后再更新數據庫,而后續的操作會把數據再裝載的緩存中。然而,這個是邏輯是錯誤的。試想,兩個并發操作,一個是更新操作,另一個是查詢操作,更新操作刪除緩存后,查詢操作沒有***緩存,先把老數據讀出來后放到緩存中,然后更新操作更新了數據庫。于是,在緩存中的數據還是老的數據,導致緩存中的數據是臟的,而且還一直這樣臟下去了。

[[259724]]

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

責任編輯:武曉燕 來源: 酷殼
相關推薦

2016-10-28 21:47:44

開發經驗Android

2018-12-29 10:37:05

HTTP緩存URL

2017-01-12 21:02:29

Windows 10系統更新

2015-09-18 13:08:36

更新RedstoneWindows 10

2018-07-06 15:04:24

緩存token線程

2010-03-24 15:40:39

網管運維管理摩卡軟件

2020-10-27 07:34:41

基站手機蜂窩網絡

2024-04-17 08:11:01

數據庫事務流程

2023-03-03 11:12:34

Kubernetes控制器后端

2015-06-30 11:52:30

2023-11-07 07:21:04

2018-10-19 11:07:02

主流緩存更新

2022-11-04 19:00:00

架構

2015-09-06 09:09:13

2014-06-20 10:34:42

開源

2015-11-10 09:09:23

代碼程序員成長

2024-03-28 08:13:51

GPTsOpenAI人工智能

2011-11-25 09:48:04

天線無線

2013-08-19 16:17:48

CIO

2009-09-02 20:18:17

域名劫持域名安全
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 欧美精品91 | www.日韩 | 中文字幕日韩欧美 | 国产一二三视频在线观看 | 91视频官网| 日日干天天操 | 午夜影院网站 | 巨大黑人极品videos精品 | 国产免费人成xvideos视频 | 99国产精品视频免费观看一公开 | 嫩草国产 | 欧美日韩电影一区二区 | 国产不卡在线播放 | 国产精品一区在线 | 成人高清在线 | 国产精品美女久久久久久免费 | 国产精品久久久久久久久久三级 | 亚洲成人精品一区 | 日韩欧美亚洲 | 99精品久久久国产一区二区三 | 在线免费观看黄视频 | 91精品国产色综合久久不卡蜜臀 | 欧美国产日韩在线观看成人 | 91久久综合 | 一级黄色毛片a | 日韩精品免费看 | 99久久免费精品国产男女高不卡 | 精品一区二区不卡 | 狠狠操狠狠干 | 欧美黑人一级爽快片淫片高清 | 欧美成人精品一区二区男人看 | 亚洲免费视频一区 | 久久精品日产第一区二区三区 | 亚洲成a人片 | 91欧美| 久久亚洲一区 | 国产激情91久久精品导航 | 亚洲经典一区 | 粉嫩粉嫩芽的虎白女18在线视频 | 日本三级电影在线观看视频 | 欧美一区二区三区在线看 |