看到好些人在寫更新緩存數(shù)據(jù)代碼時(shí)佃蚜，先刪除緩存庸娱，然后再更新數(shù)據(jù)庫(kù)着绊，而后續(xù)的操作會(huì)把數(shù)據(jù)再裝載的緩存中。然而熟尉，這個(gè)是邏輯是錯(cuò)誤的归露。試想，兩個(gè)并發(fā)操作斤儿，一個(gè)是更新操作靶擦，另一個(gè)是查詢操作，更新操作刪除緩存后雇毫，查詢操作沒有命中緩存，先把老數(shù)據(jù)讀出來后放到緩存中踩蔚，然后更新操作更新了數(shù)據(jù)庫(kù)棚放。于是，在緩存中的數(shù)據(jù)還是老的數(shù)據(jù)馅闽，導(dǎo)致緩存中的數(shù)據(jù)是臟的飘蚯，而且還一直這樣臟下去了。
我不知道為什么這么多人用的都是這個(gè)邏輯福也，當(dāng)我在微博上發(fā)了這個(gè)貼以后局骤，我發(fā)現(xiàn)好些人給了好多非常復(fù)雜和詭異的方案，所以暴凑，我想寫這篇文章說一下幾個(gè)緩存更新的Design Pattern（讓我們多一些套路吧）峦甩。
這里，我們先不討論更新緩存和更新數(shù)據(jù)這兩個(gè)事是一個(gè)事務(wù)的事现喳，或是會(huì)有失敗的可能凯傲，我們先假設(shè)更新數(shù)據(jù)庫(kù)和更新緩存都可以成功的情況（我們先把成功的代碼邏輯先寫對(duì)）。
更新緩存的的Design Pattern有四種：Cache aside, Read through, Write through, Write behind caching嗦篱，我們下面一一來看一下這四種Pattern冰单。
Cache Aside Pattern
這是最常用最常用的pattern了。其具體邏輯如下：
失效：應(yīng)用程序先從cache取數(shù)據(jù)灸促，沒有得到诫欠，則從數(shù)據(jù)庫(kù)中取數(shù)據(jù)，成功后浴栽，放到緩存中荒叼。
命中：應(yīng)用程序從cache中取數(shù)據(jù)，取到后返回吃度。
更新：先把數(shù)據(jù)存到數(shù)據(jù)庫(kù)中甩挫，成功后，再讓緩存失效椿每。
[圖片上傳失敗...(image-45908a-1576510255536)]
注意伊者，我們的更新是先更新數(shù)據(jù)庫(kù)英遭，成功后，讓緩存失效亦渗。那么挖诸，這種方式是否可以沒有文章前面提到過的那個(gè)問題呢？我們可以腦補(bǔ)一下法精。
一個(gè)是查詢操作多律，一個(gè)是更新操作的并發(fā)，首先搂蜓，沒有了刪除cache數(shù)據(jù)的操作了狼荞，而是先更新了數(shù)據(jù)庫(kù)中的數(shù)據(jù)，此時(shí)帮碰，緩存依然有效相味，所以，并發(fā)的查詢操作拿的是沒有更新的數(shù)據(jù)殉挽，但是丰涉，更新操作馬上讓緩存的失效了，后續(xù)的查詢操作再把數(shù)據(jù)從數(shù)據(jù)庫(kù)中拉出來斯碌。而不會(huì)像文章開頭的那個(gè)邏輯產(chǎn)生的問題一死，后續(xù)的查詢操作一直都在取老的數(shù)據(jù)。
這是標(biāo)準(zhǔn)的design pattern傻唾，包括Facebook的論文《Scaling Memcache at Facebook》也使用了這個(gè)策略投慈。為什么不是寫完數(shù)據(jù)庫(kù)后更新緩存？你可以看一下Quora上的這個(gè)問答《Why does Facebook use delete to remove the key-value pair in Memcached instead of updating the Memcached during write request to the backend?》冠骄，主要是怕兩個(gè)并發(fā)的寫操作導(dǎo)致臟數(shù)據(jù)逛裤。
那么，是不是Cache Aside這個(gè)就不會(huì)有并發(fā)問題了猴抹？不是的带族，比如，一個(gè)是讀操作蟀给，但是沒有命中緩存蝙砌，然后就到數(shù)據(jù)庫(kù)中取數(shù)據(jù)，此時(shí)來了一個(gè)寫操作跋理，寫完數(shù)據(jù)庫(kù)后择克，讓緩存失效，然后前普，之前的那個(gè)讀操作再把老的數(shù)據(jù)放進(jìn)去肚邢，所以，會(huì)造成臟數(shù)據(jù)。
但骡湖，這個(gè)case理論上會(huì)出現(xiàn)贱纠，不過，實(shí)際上出現(xiàn)的概率可能非常低响蕴，因?yàn)檫@個(gè)條件需要發(fā)生在讀緩存時(shí)緩存失效谆焊，而且并發(fā)著有一個(gè)寫操作。而實(shí)際上數(shù)據(jù)庫(kù)的寫操作會(huì)比讀操作慢得多浦夷，而且還要鎖表辖试，而讀操作必需在寫操作前進(jìn)入數(shù)據(jù)庫(kù)操作，而又要晚于寫操作更新緩存劈狐，所有的這些條件都具備的概率基本并不大罐孝。
所以，這也就是Quora上的那個(gè)答案里說的肥缔，要么通過2PC或是Paxos協(xié)議保證一致性肾档，要么就是拼命的降低并發(fā)時(shí)臟數(shù)據(jù)的概率，而Facebook使用了這個(gè)降低概率的玩法辫继，因?yàn)?PC太慢，而Paxos太復(fù)雜俗慈。當(dāng)然姑宽，最好還是為緩存設(shè)置上過期時(shí)間。
Read/Write Through Pattern
我們可以看到闺阱，在上面的Cache Aside套路中炮车，我們的應(yīng)用代碼需要維護(hù)兩個(gè)數(shù)據(jù)存儲(chǔ)，一個(gè)是緩存（Cache）酣溃，一個(gè)是數(shù)據(jù)庫(kù)（Repository）瘦穆。所以，應(yīng)用程序比較啰嗦赊豌。而Read/Write Through套路是把更新數(shù)據(jù)庫(kù)（Repository）的操作由緩存自己代理了扛或，所以，對(duì)于應(yīng)用層來說碘饼，就簡(jiǎn)單很多了熙兔。可以理解為，應(yīng)用認(rèn)為后端就是一個(gè)單一的存儲(chǔ)艾恼，而存儲(chǔ)自己維護(hù)自己的Cache住涉。
Read Through
Read Through 套路就是在查詢操作中更新緩存，也就是說钠绍，當(dāng)緩存失效的時(shí)候（過期或LRU換出）舆声，Cache Aside是由調(diào)用方負(fù)責(zé)把數(shù)據(jù)加載入緩存，而Read Through則用緩存服務(wù)自己來加載柳爽，從而對(duì)應(yīng)用方是透明的媳握。
Write Through
Write Through 套路和Read Through相仿碱屁，不過是在更新數(shù)據(jù)時(shí)發(fā)生。當(dāng)有數(shù)據(jù)更新的時(shí)候毙芜，如果沒有命中緩存忽媒，直接更新數(shù)據(jù)庫(kù)，然后返回腋粥。如果命中了緩存晦雨，則更新緩存，然后再由Cache自己更新數(shù)據(jù)庫(kù)（這是一個(gè)同步操作）
下圖自來Wikipedia的Cache詞條隘冲。其中的Memory你可以理解為就是我們例子里的數(shù)據(jù)庫(kù)闹瞧。
Write Behind Caching Pattern
Write Behind 又叫 Write Back。一些了解Linux操作系統(tǒng)內(nèi)核的同學(xué)對(duì)write back應(yīng)該非常熟悉展辞，這不就是Linux文件系統(tǒng)的Page Cache的算法嗎奥邮？是的，你看基礎(chǔ)這玩意全都是相通的罗珍。所以洽腺，基礎(chǔ)很重要，我已經(jīng)不是一次說過基礎(chǔ)很重要這事了覆旱。
Write Back套路蘸朋，一句說就是，在更新數(shù)據(jù)的時(shí)候扣唱，只更新緩存藕坯，不更新數(shù)據(jù)庫(kù)，而我們的緩存會(huì)異步地批量更新數(shù)據(jù)庫(kù)噪沙。這個(gè)設(shè)計(jì)的好處就是讓數(shù)據(jù)的I/O操作飛快無比（因?yàn)橹苯硬僮鲀?nèi)存嘛 ）炼彪，因?yàn)楫惒剑瑆rite backg還可以合并對(duì)同一個(gè)數(shù)據(jù)的多次操作正歼，所以性能的提高是相當(dāng)可觀的辐马。
但是，其帶來的問題是局义，數(shù)據(jù)不是強(qiáng)一致性的齐疙，而且可能會(huì)丟失（我們知道Unix/Linux非正常關(guān)機(jī)會(huì)導(dǎo)致數(shù)據(jù)丟失，就是因?yàn)檫@個(gè)事）旭咽。在軟件設(shè)計(jì)上贞奋，我們基本上不可能做出一個(gè)沒有缺陷的設(shè)計(jì)，就像算法設(shè)計(jì)中的時(shí)間換空間穷绵，空間換時(shí)間一個(gè)道理轿塔，有時(shí)候，強(qiáng)一致性和高性能，高可用和高性性是有沖突的勾缭。軟件設(shè)計(jì)從來都是取舍Trade-Off揍障。
另外，Write Back實(shí)現(xiàn)邏輯比較復(fù)雜俩由，因?yàn)樗枰猼rack有哪數(shù)據(jù)是被更新了的毒嫡，需要刷到持久層上。操作系統(tǒng)的write back會(huì)在僅當(dāng)這個(gè)cache需要失效的時(shí)候幻梯，才會(huì)被真正持久起來兜畸，比如，內(nèi)存不夠了碘梢，或是進(jìn)程退出了等情況咬摇，這又叫l(wèi)azy write。
在wikipedia上有一張write back的流程圖煞躬，基本邏輯如下：
再多嘮叨一些
1）上面講的這些Design Pattern肛鹏，其實(shí)并不是軟件架構(gòu)里的mysql數(shù)據(jù)庫(kù)和memcache/redis的更新策略，這些東西都是計(jì)算機(jī)體系結(jié)構(gòu)里的設(shè)計(jì)恩沛，比如CPU的緩存在扰，硬盤文件系統(tǒng)中的緩存，硬盤上的緩存雷客，數(shù)據(jù)庫(kù)中的緩存芒珠。基本上來說，這些緩存更新的設(shè)計(jì)模式都是非常老古董的佛纫，而且歷經(jīng)長(zhǎng)時(shí)間考驗(yàn)的策略，所以這也就是总放，工程學(xué)上所謂的Best Practice呈宇，遵從就好了。
2）有時(shí)候局雄，我們覺得能做宏觀的系統(tǒng)架構(gòu)的人一定是很有經(jīng)驗(yàn)的甥啄，其實(shí)，宏觀系統(tǒng)架構(gòu)中的很多設(shè)計(jì)都來源于這些微觀的東西炬搭。比如蜈漓，云計(jì)算中的很多虛擬化技術(shù)的原理，和傳統(tǒng)的虛擬內(nèi)存不是很像么宫盔？Unix下的那些I/O模型融虽，也放大到了架構(gòu)里的同步異步的模型咒精，還有Unix發(fā)明的管道不就是數(shù)據(jù)流式計(jì)算架構(gòu)嗎厢破？TCP的好些設(shè)計(jì)也用在不同系統(tǒng)間的通訊中粉楚，仔細(xì)看看這些微觀層面，你會(huì)發(fā)現(xiàn)有很多設(shè)計(jì)都非常精妙……所以输吏，請(qǐng)?jiān)试S我在這里放句觀點(diǎn)鮮明的話——如果你要做好架構(gòu)，首先你得把計(jì)算機(jī)體系結(jié)構(gòu)以及很多老古董的基礎(chǔ)技術(shù)吃透了纷宇。
3）在軟件開發(fā)或設(shè)計(jì)中孔飒，我非常建議在之前先去參考一下已有的設(shè)計(jì)和思路，看看相應(yīng)的guideline萤衰，best practice或design pattern堕义，吃透了已有的這些東西，再?zèng)Q定是否要重新發(fā)明輪子脆栋。千萬不要似是而非地倦卖，想當(dāng)然的做軟件設(shè)計(jì)。
4）上面筹吐，我們沒有考慮緩存（Cache）和持久層（Repository）的整體事務(wù)的問題糖耸。比如，更新Cache成功丘薛，更新數(shù)據(jù)庫(kù)失敗了怎么嗎嘉竟？或是反過來。關(guān)于這個(gè)事洋侨，如果你需要強(qiáng)一致性舍扰，你需要使用“兩階段提交協(xié)議”——prepare, commit/rollback，比如Java 7 的XAResource希坚，還有MySQL 5.7的 XA Transaction边苹，有些cache也支持XA，比如EhCache裁僧。當(dāng)然个束，XA這樣的強(qiáng)一致性的玩法會(huì)導(dǎo)致性能下降，關(guān)于分布式的事務(wù)的相關(guān)話題聊疲，你可以看看《分布式系統(tǒng)的事務(wù)處理》一文茬底。
（全文完）
轉(zhuǎn)載自 [緩存更新的套路]（https://coolshell.cn/articles/17416.html）
