看到好些人在寫更新緩存數(shù)據(jù)代碼時，先刪除緩存儒士，然后再更新數(shù)據(jù)庫的止，而后續(xù)的操作會把數(shù)據(jù)再裝載的緩存中。然而着撩，這個是邏輯是錯誤的诅福。試想，兩個并發(fā)操作拖叙，一個是更新操作氓润，另一個是查詢操作，更新操作刪除緩存后薯鳍，查詢操作沒有命中緩存咖气，先把老數(shù)據(jù)讀出來后放到緩存中，然后更新操作更新了數(shù)據(jù)庫挖滤。于是崩溪，在緩存中的數(shù)據(jù)還是老的數(shù)據(jù)，導(dǎo)致緩存中的數(shù)據(jù)是臟的斩松，而且還一直這樣臟下去了伶唯。
我不知道為什么這么多人用的都是這個邏輯，當(dāng)我在微博上發(fā)了這個貼以后惧盹，我發(fā)現(xiàn)好些人給了好多非常復(fù)雜和詭異的方案乳幸，所以奋救，我想寫這篇文章說一下幾個緩存更新的Design Pattern（讓我們多一些套路吧）。
這里反惕，我們先不討論更新緩存和更新數(shù)據(jù)這兩個事是一個事務(wù)的事尝艘，或是會有失敗的可能，我們先假設(shè)更新數(shù)據(jù)庫和更新緩存都可以成功的情況（我們先把成功的代碼邏輯先寫對）姿染。
更新緩存的的Design Pattern有四種：Cache aside, Read through, Write through, Write behind caching背亥，我們下面一一來看一下這四種Pattern。
Cache Aside Pattern
這是最常用最常用的pattern了悬赏。其具體邏輯如下：
失效：應(yīng)用程序先從cache取數(shù)據(jù)狡汉，沒有得到，則從數(shù)據(jù)庫中取數(shù)據(jù)闽颇，成功后盾戴，放到緩存中。
命中：應(yīng)用程序從cache中取數(shù)據(jù)兵多，取到后返回尖啡。
更新：先把數(shù)據(jù)存到數(shù)據(jù)庫中，成功后剩膘，再讓緩存失效衅斩。
注意，我們的更新是先更新數(shù)據(jù)庫怠褐，成功后畏梆，讓緩存失效。那么奈懒，這種方式是否可以沒有文章前面提到過的那個問題呢奠涌？我們可以腦補一下。
一個是查詢操作磷杏，一個是更新操作的并發(fā)溜畅，首先，沒有了刪除cache數(shù)據(jù)的操作了茴丰，而是先更新了數(shù)據(jù)庫中的數(shù)據(jù)达皿，此時，緩存依然有效贿肩，所以峦椰，并發(fā)的查詢操作拿的是沒有更新的數(shù)據(jù)，但是汰规，更新操作馬上讓緩存的失效了汤功，后續(xù)的查詢操作再把數(shù)據(jù)從數(shù)據(jù)庫中拉出來。而不會像文章開頭的那個邏輯產(chǎn)生的問題溜哮，后續(xù)的查詢操作一直都在取老的數(shù)據(jù)滔金。
這是標(biāo)準(zhǔn)的design pattern色解，包括Facebook的論文《Scaling Memcache at Facebook》也使用了這個策略。為什么不是寫完數(shù)據(jù)庫后更新緩存餐茵？你可以看一下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?》科阎，主要是怕兩個并發(fā)的寫操作導(dǎo)致臟數(shù)據(jù)。
那么忿族，是不是Cache Aside這個就不會有并發(fā)問題了锣笨？不是的，比如道批，一個是讀操作错英，但是沒有命中緩存，然后就到數(shù)據(jù)庫中取數(shù)據(jù)隆豹，此時來了一個寫操作椭岩，寫完數(shù)據(jù)庫后，讓緩存失效璃赡，然后判哥，之前的那個讀操作再把老的數(shù)據(jù)放進(jìn)去，所以鉴吹，會造成臟數(shù)據(jù)姨伟。
但，這個case理論上會出現(xiàn)，不過瞒渠，實際上出現(xiàn)的概率可能非常低，因為這個條件需要發(fā)生在讀緩存時緩存失效伍玖，而且并發(fā)著有一個寫操作。而實際上數(shù)據(jù)庫的寫操作會比讀操作慢得多窍箍，而且還要鎖表串纺，而讀操作必需在寫操作前進(jìn)入數(shù)據(jù)庫操作，而又要晚于寫操作更新緩存椰棘，所有的這些條件都具備的概率基本并不大。
所以祷蝌，這也就是Quora上的那個答案里說的，要么通過2PC或是Paxos協(xié)議保證一致性帆卓，要么就是拼命的降低并發(fā)時臟數(shù)據(jù)的概率巨朦，而Facebook使用了這個降低概率的玩法米丘，因為2PC太慢，而Paxos太復(fù)雜拄查。當(dāng)然棚蓄，最好還是為緩存設(shè)置上過期時間。
Read/Write Through Pattern
我們可以看到癣疟，在上面的Cache Aside套路中，我們的應(yīng)用代碼需要維護(hù)兩個數(shù)據(jù)存儲睛挚，一個是緩存（Cache），一個是數(shù)據(jù)庫（Repository）扎狱。所以，應(yīng)用程序比較啰嗦匠抗。而Read/Write Through套路是把更新數(shù)據(jù)庫（Repository）的操作由緩存自己代理了污抬，所以，對于應(yīng)用層來說印机，就簡單很多了。可以理解為射赛，應(yīng)用認(rèn)為后端就是一個單一的存儲，而存儲自己維護(hù)自己的Cache竣灌。
Read Through
Read Through 套路就是在查詢操作中更新緩存秆麸，也就是說，當(dāng)緩存失效的時候（過期或LRU換出）蛔屹，Cache Aside是由調(diào)用方負(fù)責(zé)把數(shù)據(jù)加載入緩存，而Read Through則用緩存服務(wù)自己來加載，從而對應(yīng)用方是透明的漫贞。
Write Through
Write Through 套路和Read Through相仿，不過是在更新數(shù)據(jù)時發(fā)生芍殖。當(dāng)有數(shù)據(jù)更新的時候谴蔑，如果沒有命中緩存，直接更新數(shù)據(jù)庫隐锭，然后返回。如果命中了緩存钦睡，則更新緩存，然后再由Cache自己更新數(shù)據(jù)庫（這是一個同步操作）
下圖自來Wikipedia的Cache詞條洒琢。其中的Memory你可以理解為就是我們例子里的數(shù)據(jù)庫褐桌。
Write Behind Caching Pattern
Write Behind 又叫 Write Back。一些了解Linux操作系統(tǒng)內(nèi)核的同學(xué)對write back應(yīng)該非常熟悉荧嵌，這不就是Linux文件系統(tǒng)的Page Cache的算法嗎？是的恋技，你看基礎(chǔ)這玩意全都是相通的逻族。所以骄崩，基礎(chǔ)很重要聘鳞，我已經(jīng)不是一次說過基礎(chǔ)很重要這事了要拂。
Write Back套路，一句說就是脱惰，在更新數(shù)據(jù)的時候，只更新緩存，不更新數(shù)據(jù)庫旧乞，而我們的緩存會異步地批量更新數(shù)據(jù)庫磅氨。這個設(shè)計的好處就是讓數(shù)據(jù)的I/O操作飛快無比（因為直接操作內(nèi)存嘛 ），因為異步烦租，write backg還可以合并對同一個數(shù)據(jù)的多次操作，所以性能的提高是相當(dāng)可觀的叉橱。
但是，其帶來的問題是掐松，數(shù)據(jù)不是強一致性的，而且可能會丟失（我們知道Unix/Linux非正常關(guān)機會導(dǎo)致數(shù)據(jù)丟失甩栈，就是因為這個事）糕再。在軟件設(shè)計上，我們基本上不可能做出一個沒有缺陷的設(shè)計突想，就像算法設(shè)計中的時間換空間，空間換時間一個道理袭灯，有時候绑嘹，強一致性和高性能，高可用和高性性是有沖突的工腋。軟件設(shè)計從來都是取舍Trade-Off。
另外蟋恬，Write Back實現(xiàn)邏輯比較復(fù)雜趁冈，因為他需要track有哪數(shù)據(jù)是被更新了的拜马，需要刷到持久層上沐绒。操作系統(tǒng)的write back會在僅當(dāng)這個cache需要失效的時候，才會被真正持久起來洒沦，比如，內(nèi)存不夠了瞒津，或是進(jìn)程退出了等情況括尸，這又叫l(wèi)azy write。
在wikipedia上有一張write back的流程圖濒翻，基本邏輯如下：
1、上面講的這些Design Pattern淌喻，其實并不是軟件架構(gòu)里的mysql數(shù)據(jù)庫和memcache/redis的更新策略雀摘，這些東西都是計算機體系結(jié)構(gòu)里的設(shè)計，比如CPU的緩存阵赠，硬盤文件系統(tǒng)中的緩存，硬盤上的緩存匕荸，數(shù)據(jù)庫中的緩存枷邪。基本上來說，這些緩存更新的設(shè)計模式都是非常老古董的东揣，而且歷經(jīng)長時間考驗的策略，所以這也就是，工程學(xué)上所謂的Best Practice真屯，遵從就好了。
2运沦、有時候，我們覺得能做宏觀的系統(tǒng)架構(gòu)的人一定是很有經(jīng)驗的携添，其實，宏觀系統(tǒng)架構(gòu)中的很多設(shè)計都來源于這些微觀的東西羞秤。比如左敌，云計算中的很多虛擬化技術(shù)的原理，和傳統(tǒng)的虛擬內(nèi)存不是很像么矫限？Unix下的那些I/O模型，也放大到了架構(gòu)里的同步異步的模型取董，還有Unix發(fā)明的管道不就是數(shù)據(jù)流式計算架構(gòu)嗎无宿？TCP的好些設(shè)計也用在不同系統(tǒng)間的通訊中，仔細(xì)看看這些微觀層面懈贺，你會發(fā)現(xiàn)有很多設(shè)計都非常精妙……所以，請允許我在這里放句觀點鮮明的話——如果你要做好架構(gòu)画侣，首先你得把計算機體系結(jié)構(gòu)以及很多老古董的基礎(chǔ)技術(shù)吃透了堡妒。
3配乱、在軟件開發(fā)或設(shè)計中皮迟，我非常建議在之前先去參考一下已有的設(shè)計和思路，看看相應(yīng)的guideline忿檩，best practice或design pattern爆阶，吃透了已有的這些東西沙咏，再決定是否要重新發(fā)明輪子班套。千萬不要似是而非地，想當(dāng)然的做軟件設(shè)計吆豹。
4、上面痘煤，我們沒有考慮緩存（Cache）和持久層（Repository）的整體事務(wù)的問題熏挎。比如，更新Cache成功坎拐，更新數(shù)據(jù)庫失敗了怎么嗎？或是反過來都伪。關(guān)于這個事积担，如果你需要強一致性，你需要使用“兩階段提交協(xié)議”——prepare, commit/rollback帝璧，比如Java 7 的XAResource，還有MySQL 5.7的?XA Transaction褐耳，有些cache也支持XA渴庆，比如EhCache。當(dāng)然襟雷，XA這樣的強一致性的玩法會導(dǎo)致性能下降。
