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

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

在前一篇《360°全方位解讀「緩存」》中，我們聊了運用緩存的三種思路，以及在一個完整的系統中可以設立緩存的幾個位置，并且分享了關于瀏覽器緩存、CDN緩存、網關（代理）緩存的一些使用經驗。

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

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

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

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

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

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

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

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

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

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

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

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

▲圖片來源于網絡，版權歸原作者所有

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

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

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

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

但是這個方式有點“治標不治本”。不斷的從數據庫定時讀取，對資源的消耗大不說，這個間隔頻率也不好定義一個比較合適的統一標準，太短吧，會導致重復讀取的次數加大，太長吧，又會導致緩存和數據庫不一致的時間變長。

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

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

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

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

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

然后，你在事務提交之后往共享存儲中臨時存一個{ key = dbname + tablename + id，value = null，expire = 3s }這樣的數據，并且再做一次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;

如此一來，當「讀數據」的時候發生cache miss，先判斷是否存在這個臨時數據，只要在3秒內就會強制走「主庫」取數據。

可以看到，不同的方案各有利弊，需要根據具體的場景仔細權衡。

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

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

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

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

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

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

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

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

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

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

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

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

是「無限擴展」，只要堆硬件就能應對業務增長。要達到這點的背后需要滿足一個特性，就是程序要「無狀態」。那么既想引入緩存來加速，又要達到「無狀態」，靠的就是分布式緩存。

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

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

不經常變更的數據。（比如一天甚至好幾天更新一次的那種）

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

對數據準確性能容忍的場景。（比如瀏覽量，評論數等）

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

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

如果是個單點應用程序的話，很簡單，將本地緩存的操作放在最后就好了。

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

但是，本地緩存帶來的一個巨大問題就是：雖然一個節點沒問題，但是多個本地緩存節點之間的數據如何同步？

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

但是這兩個方案走的都是極端，前者變更成本太高，比如需要通知上千個節點的話，這個成本難以接受。而后者的話對資源的消耗太高，而且還容易出現壓力分攤不均勻的問題。所以，一般系統規模小的時候可以考慮前者，而規模越大越會選擇后者。

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

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

好了，我們一起總結一下。

這次呢，Z哥先花了大量的篇幅和你討論「先寫DB還是緩存」的問題，并且帶你層層深入，通過一點一點的演進來闡述不同的解決方案。

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

希望對你有所啟發。

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

相關文章：

分布式系統關注點——360°全方位解讀「緩存」

分布式系統關注點——做了「負載均衡」就可以隨便加機器了嗎？

作者：Zachary

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

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

這樣可以給我一點反饋。: )

謝謝你的舉手之勞。

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