摘要：首當(dāng)其沖的就是先寫還是緩存。先寫還是緩存一個程序可以沒有緩存，但是一定要有數(shù)據(jù)庫。為了便于記憶，你可以和分布式系統(tǒng)的定理同時記憶，叫緩存的模式。否則引入分布式緩存的作用就小了很多。就是設(shè)置緩存定時過期或者定時往下游的分布式緩存拉取最新數(shù)據(jù)。

如果第二次看到我的文章，歡迎文末掃碼訂閱我個人的公眾號（跨界架構(gòu)師）喲~  
本文長度為4209字，建議閱讀12分鐘。
堅持原創(chuàng)，每一篇都是用心之作～

在前一篇《360°全方位解讀「緩存」》中，我們聊了運(yùn)用緩存的三種思路，以及在一個完整的系統(tǒng)中可以設(shè)立緩存的幾個位置，并且分享了關(guān)于瀏覽器緩存、CDN緩存、網(wǎng)關(guān)（代理）緩存的一些使用經(jīng)驗。

這次Z哥將深入到實際場景中，來看一下「進(jìn)程內(nèi)緩存」、「進(jìn)程外緩存」運(yùn)用時的一些最佳實踐。由于篇幅原因，這次先聊三個問題。

首當(dāng)其沖的就是“先寫DB還是緩存？”。我想，只要你開始運(yùn)用緩存，這會是你第一個要好好思考的問題，否則在前方等待你的就是災(zāi)難。。。

一個程序可以沒有緩存，但是一定要有數(shù)據(jù)庫。這是大家的普遍觀點(diǎn)，所以數(shù)據(jù)庫的重要性在你的潛意識里總是被放在了第一位。

如果不細(xì)想的話你可能會覺得，數(shù)據(jù)庫操作失敗了，自然緩存也不用操作了；數(shù)據(jù)庫操作成功了，再操作緩存，沒毛病。

但是數(shù)據(jù)庫操作成功，緩存操作的失敗的情況該怎么解？（主要在用到redis，memcached這種進(jìn)程外緩存的時候，由于網(wǎng)絡(luò)因素，失敗的可能性大增）

辦法也是有的，在操作數(shù)據(jù)庫的時候帶一個事務(wù)，如果緩存操作失敗則事務(wù)回滾。大致的代碼意思如下：

begin trans
    var isDbSuccess = write db;
    if(isDbSuccess){
        var isCacheSuccess = write cache;
        if(isCacheSuccess){
            return success;
        }
        else{
            rollback db;
            return fail;
        }
    }
    else{
        return fail;
    }
    catch(Exception ex){
        rollback db;
    }
end trans

如此一來就萬無一失了嗎？并不是。除了由于事務(wù)的引入，增加了數(shù)據(jù)庫的壓力之外，在極端場景下可能會出現(xiàn)rollback db失敗的情況。是不是很頭疼？

解決這個問題的方式就是write cache的時候做delete操作，而不是set操作。如此一來，用多一次cache miss的代價來換rollback db失敗的問題。

就像圖上所示，哪怕rollback失敗了，通過一次cache miss重新從db中載入舊值。

題外話：其實這種做法有一種專業(yè)的叫法——Cache Aside Pattern。為了便于記憶，你可以和分布式系統(tǒng)的CAP定理同時記憶，叫「緩存的CAP模式」。

是不是看上去妥了？可以開始瀟灑了？

▲圖片來源于網(wǎng)絡(luò)，版權(quán)歸原作者所有

如果你的數(shù)據(jù)庫沒有做高可用的話，的確可以妥了。但是如果數(shù)據(jù)庫做了高可用，就會涉及到主從數(shù)據(jù)庫的數(shù)據(jù)同步，這就有新問題了。

題外話：所以大家不要過度追求技術(shù)的酷炫，可能會得不償失，自找麻煩。

什么問題呢？就是如果在數(shù)據(jù)還未同步到「從庫」的時候，由于cache miss去「從庫」取到了未同步前的舊值。

解決它的第一個方式很簡單，也很粗暴。就是定時去「從庫」讀數(shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)和緩存不一樣了就set到緩存里去。

但是這個方式有點(diǎn)“治標(biāo)不治本”。不斷的從數(shù)據(jù)庫定時讀取，對資源的消耗大不說，這個間隔頻率也不好定義一個比較合適的統(tǒng)一標(biāo)準(zhǔn)，太短吧，會導(dǎo)致重復(fù)讀取的次數(shù)加大，太長吧，又會導(dǎo)致緩存和數(shù)據(jù)庫不一致的時間變長。

所以這個方案僅適用于項目中只有2、3處需要做這種處理的場景，并且還不能是數(shù)據(jù)會頻繁修改的情況。因為在數(shù)據(jù)修改頻次較高的場景，甚至可能還會出現(xiàn)這個定時機(jī)制所消耗的資源反而大于主程序的情況。

一般情況下，另一種更普適性的方案是采用接下去聊的這種更底層的方式進(jìn)行，就是“哪里有問題處理哪里”，當(dāng)「從庫」完成同步的時候再額外做一次delete cache或者set cache的操作。

如此，雖說也沒有100%解決短暫的數(shù)據(jù)不一致問題，但是已經(jīng)將臟數(shù)據(jù)所存在的時長降到了最低（最終由主從同步的耗時決定），并且大大減少了無謂的資源消耗。

可能你會說，“不行，這么一點(diǎn)時間也不能忍”怎么辦？辦法是有，但是會增加「主庫」的壓力。就是在產(chǎn)生數(shù)據(jù)庫寫入動作后的一小段時間內(nèi)強(qiáng)制讀「主庫」來加載緩存。

怎么實現(xiàn)呢？先得依賴一個共享存儲，可以借助數(shù)據(jù)庫或者也可以是我們現(xiàn)在正在聊的分布式緩存。

然后，你在事務(wù)提交之后往共享存儲中臨時存一個{ key = dbname + tablename + id，value = null，expire = 3s }這樣的數(shù)據(jù)，并且再做一次delete cache的操作。

begin trans
    var isDbSuccess = write db;
    if(isDbSuccess){        
        var isCacheSuccess = delete cache;
        if(isCacheSuccess){
            return success;
        }
        else{
            rollback db;
            return fail;
        }
    }
    else{
        return fail;
    }
    catch(Exception ex){
        rollback db;
    }
end trans
?
//在這里做這個臨時存儲，{key,value,expire}。
delete cache;

如此一來，當(dāng)「讀數(shù)據(jù)」的時候發(fā)生cache miss，先判斷是否存在這個臨時數(shù)據(jù)，只要在3秒內(nèi)就會強(qiáng)制走「主庫」取數(shù)據(jù)。

可以看到，不同的方案各有利弊，需要根據(jù)具體的場景仔細(xì)權(quán)衡。

你工作中的大部分場景對數(shù)據(jù)準(zhǔn)確性肯定是低容忍的，所以一般不建議選擇「先緩存再DB」的方案，因為內(nèi)存是易失性的。一旦遇到操作緩存成功，操作DB失敗的情況，問題就來了。

在這個時候最新的數(shù)據(jù)只有緩存里有，怎么辦？多帶帶起個線程不斷的重試往數(shù)據(jù)庫寫？這個方案在一定程度上可行，但不適合用于對數(shù)據(jù)準(zhǔn)確性有高要求的場景，因為緩存一旦掛了，數(shù)據(jù)就丟了！

題外話：哪怕選擇了這個方案，重試線程應(yīng)確保只有1個，否則會存在“ABBA”的「并發(fā)寫」問題。

可能你會說用delete cache不就沒問題了？

可以是可以，但是要有個前提條件，訪問緩存的程序不會產(chǎn)生并發(fā)。因為只要你的程序是多線程運(yùn)行的，一旦出現(xiàn)并發(fā)就有可能出現(xiàn)「讀」的線程由于cache miss從數(shù)據(jù)庫取的時候，「寫」的線程還沒將數(shù)據(jù)寫到數(shù)據(jù)庫的情況。

所以，哪怕用delete cache的方式，要么帶lock（多客戶端情況下還得上分布式鎖），要么必然出現(xiàn)數(shù)據(jù)不一致。

值得注意的是，如果數(shù)據(jù)庫同樣做了高可用，哪怕帶了lock，也還需要考慮和上面提到的「先DB再緩存」中一樣的由于主從同步的時間差可能會產(chǎn)生的問題。

當(dāng)然了，「先緩存再DB」也不是一文不值。當(dāng)對寫入速度有極致要求，而對數(shù)據(jù)準(zhǔn)確性沒那么高要求的場景下就非常好使，其實就是前一篇（《360°全方位解讀「緩存」》）提到的「延遲寫」機(jī)制。

小結(jié)一下，相比緩存來說，數(shù)據(jù)庫的「高可用」一般會在系統(tǒng)發(fā)展的后期才會引入，所以在沒有引入數(shù)據(jù)庫「高可用」的情況下，Z哥建議你使用「先DB再緩存」的方式，并且緩存操作用delete而不是set，這樣基本就可以高枕無憂了。

但是如果數(shù)據(jù)庫做了「高可用」，那么團(tuán)隊必然也形成一定規(guī)模了，這個時候就老老實實的做數(shù)據(jù)庫變更記錄（binlog）的訂閱吧。

到這里可能有的小伙伴要問了，“如果上了分布式緩存，還需要本地緩存嗎？”。

在解答這個問題之前我們先來思考一個問題，一個分布式系統(tǒng)最重要的價值是什么？

是「無限擴(kuò)展」，只要堆硬件就能應(yīng)對業(yè)務(wù)增長。要達(dá)到這點(diǎn)的背后需要滿足一個特性，就是程序要「無狀態(tài)」。那么既想引入緩存來加速，又要達(dá)到「無狀態(tài)」，靠的就是分布式緩存。

所以，能用分布式緩存解決的問題就盡量不要引入本地緩存。否則引入分布式緩存的作用就小了很多。

但是在少數(shù)場景下，本地緩存還是可以發(fā)揮其價值的，但是我們需要仔細(xì)識別出來。主要是三個場景：

不經(jīng)常變更的數(shù)據(jù)。（比如一天甚至好幾天更新一次的那種）

需要支撐非常高的并發(fā)。（比如秒殺）

對數(shù)據(jù)準(zhǔn)確性能容忍的場景。（比如瀏覽量，評論數(shù)等）

不過，我還是建議你，除了第二種場景，否則還是盡量不要引入本地緩存。原因我們下面來說說。

其實這個原因的根本問題就是在引入了本地緩存后，本地緩存（進(jìn)程內(nèi)緩存）、分布式緩存（進(jìn)程外緩存）、數(shù)據(jù)庫這三者之間的數(shù)據(jù)一致性該怎么進(jìn)行呢？

如果是個單點(diǎn)應(yīng)用程序的話，很簡單，將本地緩存的操作放在最后就好了。

可能你會說本地緩存修改失敗怎么辦？比如重復(fù)key啊什么的異常。那你可以反思一下為這種數(shù)據(jù)為什么可以成功的寫進(jìn)數(shù)據(jù)庫。。。

但是，本地緩存帶來的一個巨大問題就是：雖然一個節(jié)點(diǎn)沒問題，但是多個本地緩存節(jié)點(diǎn)之間的數(shù)據(jù)如何同步？

解決這個問題的方式中有兩種和之前我們聊過的Session問題（《做了「負(fù)載均衡」就可以隨便加機(jī)器了嗎？》）是類似的。要么是由接收修改的節(jié)點(diǎn)通知其它節(jié)點(diǎn)變更（通過rpc或者mq皆可），要么借助一致性hash讓同一個來源的請求固定落到一個節(jié)點(diǎn)上。后者可以讓不同節(jié)點(diǎn)上的本地緩存數(shù)據(jù)都不重復(fù)，從源頭上避免了這個問題。

但是這兩個方案走的都是極端，前者變更成本太高，比如需要通知上千個節(jié)點(diǎn)的話，這個成本難以接受。而后者的話對資源的消耗太高，而且還容易出現(xiàn)壓力分?jǐn)偛痪鶆虻膯栴}。所以，一般系統(tǒng)規(guī)模小的時候可以考慮前者，而規(guī)模越大越會選擇后者。

還有一種相對中庸一些的，以降低數(shù)據(jù)的準(zhǔn)確性來換成本的方案。就是設(shè)置緩存定時過期或者定時往下游的分布式緩存拉取最新數(shù)據(jù)。這和前面「先DB再緩存」中提到的定時機(jī)制是一樣的邏輯，勝在簡單，缺點(diǎn)就是會存在更長時間的數(shù)據(jù)不一致。

小結(jié)一下，本地緩存的數(shù)據(jù)一致性解決方案，能徹底解決的是借助一致性hash的方案，但是成本比較高。所以，如非必要還是慎重決定要不要做本地緩存。

好了，我們一起總結(jié)一下。

這次呢，Z哥先花了大量的篇幅和你討論「先寫DB還是緩存」的問題，并且?guī)銓訉由钊?，通過一點(diǎn)一點(diǎn)的演進(jìn)來闡述不同的解決方案。

然后與你討論了「本地緩存」的意義以及如何在「分布式緩存」和「數(shù)據(jù)庫」的基礎(chǔ)上做好數(shù)據(jù)一致性，這其中主要是多個本地緩存節(jié)點(diǎn)之間的數(shù)據(jù)同步問題。

希望對你有所啟發(fā)。

這次的緩存實踐是一個非常好的例子，從中我們可以看到一件事情的精細(xì)化所帶來的復(fù)雜度需要更加的精細(xì)化去解決，但是又會帶來新的復(fù)雜度。所以作為技術(shù)人的你，需要無時無刻考慮該怎么權(quán)衡，而不是人云亦云。

相關(guān)文章：

分布式系統(tǒng)關(guān)注點(diǎn)——360°全方位解讀「緩存」

分布式系統(tǒng)關(guān)注點(diǎn)——做了「負(fù)載均衡」就可以隨便加機(jī)器了嗎？

作者：Zachary

出處：https://www.cnblogs.com/Zacha...

如果你喜歡這篇文章，可以點(diǎn)一下文末的「贊」。

這樣可以給我一點(diǎn)反饋。: )

謝謝你的舉手之勞。

?關(guān)于作者：張帆（Zachary，個人微信號：Zachary-ZF）。堅持用心打磨每一篇高質(zhì)量原創(chuàng)。歡迎掃描下方的二維碼~。
定期發(fā)表原創(chuàng)內(nèi)容：架構(gòu)設(shè)計丨分布式系統(tǒng)丨產(chǎn)品丨運(yùn)營丨一些思考。
如果你是初級程序員，想提升但不知道如何下手。又或者做程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關(guān)注我的公眾號「跨界架構(gòu)師」，回復(fù)「技術(shù)」，送你一份我長期收集和整理的思維導(dǎo)圖。
如果你是運(yùn)營，面對不斷變化的市場束手無策。又或者想了解主流的運(yùn)營策略，以豐富自己的“倉庫”。歡迎關(guān)注我的公眾號「跨界架構(gòu)師」，回復(fù)「運(yùn)營」，送你一份我長期收集和整理的思維導(dǎo)圖。