两难！先更新数据库再删缓存？还是先删缓存再更新数据库？
前言
當我們在做數(shù)據(jù)庫與緩存數(shù)據(jù)同步時，究竟更新緩存，還是刪除緩存，究竟是先操作數(shù)據(jù)庫，還是先操作緩存？本文帶大家深度分析數(shù)據(jù)庫與緩存的雙寫問題，并且給出了所有方案的實現(xiàn)代碼方便大家參考。
本篇文章主要內容
數(shù)據(jù)緩存
為何要使用緩存
哪類數(shù)據(jù)適合緩存
緩存的利與弊
如何保證緩存和數(shù)據(jù)庫一致性
不更新緩存，而是刪除緩存
先操作緩存，還是先操作數(shù)據(jù)庫
非要保證數(shù)據(jù)庫和緩存數(shù)據(jù)強一致該怎么辦
緩存和數(shù)據(jù)庫一致性實戰(zhàn)
實戰(zhàn)：先刪除緩存，再更新數(shù)據(jù)庫
實戰(zhàn)：先更新數(shù)據(jù)庫，再刪緩存
實戰(zhàn)：緩存延時雙刪
實戰(zhàn)：刪除緩存重試機制
實戰(zhàn)：讀取binlog異步刪除緩存
數(shù)據(jù)緩存
在我們實際的業(yè)務場景中，一定有很多需要做數(shù)據(jù)緩存的場景，比如售賣商品的頁面，包括了許多并發(fā)訪問量很大的數(shù)據(jù)，它們可以稱作是是“熱點”數(shù)據(jù)，這些數(shù)據(jù)有一個特點，就是更新頻率低，讀取頻率高，這些數(shù)據(jù)應該盡量被緩存，從而減少請求打到數(shù)據(jù)庫上的機會，減輕數(shù)據(jù)庫的壓力。
為何要使用緩存
緩存是為了追求“快”而存在的。我們用代碼舉一個例子。
我在自己的Demo代碼倉庫中增加了兩個查詢庫存的接口getStockByDB和getStockByCache，分別表示從數(shù)據(jù)庫和緩存查詢某商品的庫存量。
隨后我們用JMeter進行并發(fā)請求測試。（JMeter的使用請參考我之前寫的文章：點擊這里）
需要聲明的是，我的測試并不嚴謹，只是作對比測試，不要作為實際服務性能的參考。
這是兩個接口的代碼：
/***?查詢庫存：通過數(shù)據(jù)庫查詢庫存*?@param?sid*?@return*/ @RequestMapping("/getStockByDB/{sid}") @ResponseBody public?String?getStockByDB(@PathVariable?int?sid)?{int?count;try?{count?=?stockService.getStockCountByDB(sid);}?catch?(Exception?e)?{LOGGER.error("查詢庫存失敗：[{}]",?e.getMessage());return?"查詢庫存失敗";}LOGGER.info("商品Id:?[{}]?剩余庫存為:?[{}]",?sid,?count);return?String.format("商品Id:?%d 剩余庫存為：%d",?sid,?count); }/***?查詢庫存：通過緩存查詢庫存*?緩存命中：返回庫存*?緩存未命中：查詢數(shù)據(jù)庫寫入緩存并返回*?@param?sid*?@return*/ @RequestMapping("/getStockByCache/{sid}") @ResponseBody public?String?getStockByCache(@PathVariable?int?sid)?{Integer?count;try?{count?=?stockService.getStockCountByCache(sid);if?(count?==?null)?{count?=?stockService.getStockCountByDB(sid);LOGGER.info("緩存未命中，查詢數(shù)據(jù)庫，并寫入緩存");stockService.setStockCountToCache(sid,?count);}}?catch?(Exception?e)?{LOGGER.error("查詢庫存失敗：[{}]",?e.getMessage());return?"查詢庫存失敗";}LOGGER.info("商品Id:?[{}]?剩余庫存為:?[{}]",?sid,?count);return?String.format("商品Id:?%d 剩余庫存為：%d",?sid,?count); }首先設置為10000個并發(fā)請求的情況下，運行JMeter，結果首先出現(xiàn)了大量的報錯，10000個請求中98%的請求都直接失敗了。讓人很慌張~
打開日志，報錯如下：
SpringBoot內置的Tomcat最大并發(fā)數(shù)搞的鬼，其默認值為200，對于10000的并發(fā)，單機服務實在是力不從心。當然，你可以修改這里的并發(fā)數(shù)設置，但是你的小機器仍然可能會扛不住。
將其修改為如下配置后，我的小機器才在通過緩存拿庫存的情況下，保證了10000個并發(fā)的100%返回請求：
server.tomcat.max-threads=10000 server.tomcat.max-connections=10000可以看到，不使用緩存的情況下，吞吐量為668個請求每秒：
使用緩存的情況下，吞吐量為2177個請求每秒：
在這種“十分不嚴謹”的對比下，有緩存對于一臺單機，性能提升了3倍多，如果在多臺機器，更多并發(fā)的情況下，由于數(shù)據(jù)庫有了更大的壓力，緩存的性能優(yōu)勢應該會更加明顯。
測完了這個小實驗，我看了眼我掛著MySql的小水管騰訊云服務器，生怕他被這么高流量搞掛。這種突發(fā)的流量，指不定會被檢測為異常攻擊流量呢~
我用的是騰訊云服務器1C4G2M，活動買的，很便宜。這里打個免費的廣告，請騰訊云看到后聯(lián)系我給我打錢 ;)
哪類數(shù)據(jù)適合緩存
緩存量大但又不常變化的數(shù)據(jù)，比如詳情，評論等。對于那些經(jīng)常變化的數(shù)據(jù)，其實并不適合緩存，一方面會增加系統(tǒng)的復雜性（緩存的更新，緩存臟數(shù)據(jù)），另一方面也給系統(tǒng)帶來一定的不穩(wěn)定性（緩存系統(tǒng)的維護）。
但一些極端情況下，你需要將一些會變動的數(shù)據(jù)進行緩存，比如想要頁面顯示準實時的庫存數(shù)，或者其他一些特殊業(yè)務場景。這時候你需要保證緩存不能（一直）有臟數(shù)據(jù)，這就需要再深入討論一下。
緩存的利與弊
我們到底該不該上緩存的，這其實也是個trade-off（權衡）的問題。
上緩存的優(yōu)點：
能夠縮短服務的響應時間，給用戶帶來更好的體驗。
能夠增大系統(tǒng)的吞吐量，依然能夠提升用戶體驗。
減輕數(shù)據(jù)庫的壓力，防止高峰期數(shù)據(jù)庫被壓垮，導致整個線上服務BOOM！
上了緩存，也會引入很多額外的問題：
緩存有多種選型，是內存緩存，memcached還是redis，你是否都熟悉，如果不熟悉，無疑增加了維護的難度（本來是個純潔的數(shù)據(jù)庫系統(tǒng)）。
緩存系統(tǒng)也要考慮分布式，比如redis的分布式緩存還會有很多坑，無疑增加了系統(tǒng)的復雜性。
在特殊場景下，如果對緩存的準確性有非常高的要求，就必須考慮緩存和數(shù)據(jù)庫的一致性問題。
本文想要重點討論的，就是緩存和數(shù)據(jù)庫的一致性問題，各位看官且往下看。
如何保證緩存和數(shù)據(jù)庫一致性
說了這么多緩存的必要性，那么使用緩存是不是就是一個很簡單的事情了呢，我之前也一直是這么覺得的，直到遇到了需要緩存與數(shù)據(jù)庫保持強一致的場景，才知道讓數(shù)據(jù)庫數(shù)據(jù)和緩存數(shù)據(jù)保持一致性是一門很高深的學問。
從遠古的硬件緩存，操作系統(tǒng)緩存開始，緩存就是一門獨特的學問。這個問題也被業(yè)界探討了非常久，爭論至今。我翻閱了很多資料，發(fā)現(xiàn)其實這是一個權衡的問題。值得好好講講。
以下的討論會引入幾方觀點，我會跟著觀點來寫代碼驗證所提到的問題。
不更新緩存，而是刪除緩存
大部分觀點認為，做緩存不應該是去更新緩存，而是應該刪除緩存，然后由下個請求去去緩存，發(fā)現(xiàn)不存在后再讀取數(shù)據(jù)庫，寫入緩存。
觀點引用：《分布式之數(shù)據(jù)庫和緩存雙寫一致性方案解析》孤獨煙
原因一：線程安全角度
同時有請求A和請求B進行更新操作，那么會出現(xiàn)
（1）線程A更新了數(shù)據(jù)庫
（2）線程B更新了數(shù)據(jù)庫
（3）線程B更新了緩存
（4）線程A更新了緩存
這就出現(xiàn)請求A更新緩存應該比請求B更新緩存早才對，但是因為網(wǎng)絡等原因，B卻比A更早更新了緩存。這就導致了臟數(shù)據(jù)，因此不考慮。
原因二：業(yè)務場景角度
有如下兩點：
（1）如果你是一個寫數(shù)據(jù)庫場景比較多，而讀數(shù)據(jù)場景比較少的業(yè)務需求，采用這種方案就會導致，數(shù)據(jù)壓根還沒讀到，緩存就被頻繁的更新，浪費性能。
（2）如果你寫入數(shù)據(jù)庫的值，并不是直接寫入緩存的，而是要經(jīng)過一系列復雜的計算再寫入緩存。那么，每次寫入數(shù)據(jù)庫后，都再次計算寫入緩存的值，無疑是浪費性能的。顯然，刪除緩存更為適合。
其實如果業(yè)務非常簡單，只是去數(shù)據(jù)庫拿一個值，寫入緩存，那么更新緩存也是可以的。但是，淘汰緩存操作簡單，并且?guī)淼母弊饔弥皇窃黾恿艘淮蝐ache miss，建議作為通用的處理方式。
先操作緩存，還是先操作數(shù)據(jù)庫
那么問題就來了，我們是先刪除緩存，然后再更新數(shù)據(jù)庫，還是先更新數(shù)據(jù)庫，再刪緩存呢？
先來看看大佬們怎么說。
《【58沈劍架構系列】緩存架構設計細節(jié)二三事》58沈劍：
對于一個不能保證事務性的操作，一定涉及“哪個任務先做，哪個任務后做”的問題，解決這個問題的方向是：如果出現(xiàn)不一致，誰先做對業(yè)務的影響較小，就誰先執(zhí)行。
假設先淘汰緩存，再寫數(shù)據(jù)庫：第一步淘汰緩存成功，第二步寫數(shù)據(jù)庫失敗，則只會引發(fā)一次Cache miss。
假設先寫數(shù)據(jù)庫，再淘汰緩存：第一步寫數(shù)據(jù)庫操作成功，第二步淘汰緩存失敗，則會出現(xiàn)DB中是新數(shù)據(jù)，Cache中是舊數(shù)據(jù)，數(shù)據(jù)不一致。
沈劍老師說的沒有問題，不過沒完全考慮好并發(fā)請求時的數(shù)據(jù)臟讀問題，讓我們再來看看孤獨煙老師《分布式之數(shù)據(jù)庫和緩存雙寫一致性方案解析》：
先刪緩存，再更新數(shù)據(jù)庫
該方案會導致請求數(shù)據(jù)不一致
同時有一個請求A進行更新操作，另一個請求B進行查詢操作。那么會出現(xiàn)如下情形:
（1）請求A進行寫操作，刪除緩存
（2）請求B查詢發(fā)現(xiàn)緩存不存在
（3）請求B去數(shù)據(jù)庫查詢得到舊值
（4）請求B將舊值寫入緩存
（5）請求A將新值寫入數(shù)據(jù)庫
上述情況就會導致不一致的情形出現(xiàn)。而且，如果不采用給緩存設置過期時間策略，該數(shù)據(jù)永遠都是臟數(shù)據(jù)。
所以先刪緩存，再更新數(shù)據(jù)庫并不是一勞永逸的解決方案，再看看先更新數(shù)據(jù)庫，再刪緩存這種方案怎么樣？
先更新數(shù)據(jù)庫，再刪緩存這種情況不存在并發(fā)問題么？
不是的。假設這會有兩個請求，一個請求A做查詢操作，一個請求B做更新操作，那么會有如下情形產生
（1）緩存剛好失效
（2）請求A查詢數(shù)據(jù)庫，得一個舊值
（3）請求B將新值寫入數(shù)據(jù)庫
（4）請求B刪除緩存
（5）請求A將查到的舊值寫入緩存
ok，如果發(fā)生上述情況，確實是會發(fā)生臟數(shù)據(jù)。
然而，發(fā)生這種情況的概率又有多少呢？
發(fā)生上述情況有一個先天性條件，就是步驟（3）的寫數(shù)據(jù)庫操作比步驟（2）的讀數(shù)據(jù)庫操作耗時更短，才有可能使得步驟（4）先于步驟（5）。可是，大家想想，數(shù)據(jù)庫的讀操作的速度遠快于寫操作的（不然做讀寫分離干嘛，做讀寫分離的意義就是因為讀操作比較快，耗資源少），因此步驟（3）耗時比步驟（2）更短，這一情形很難出現(xiàn)。
先更新數(shù)據(jù)庫，再刪緩存依然會有問題，不過，問題出現(xiàn)的可能性會因為上面說的原因，變得比較低！
所以，如果你想實現(xiàn)基礎的緩存數(shù)據(jù)庫雙寫一致的邏輯，那么在大多數(shù)情況下，在不想做過多設計，增加太大工作量的情況下，請先更新數(shù)據(jù)庫，再刪緩存!
我非要數(shù)據(jù)庫和緩存數(shù)據(jù)強一致怎么辦
那么，如果我非要保證絕對一致性怎么辦，先給出結論：
沒有辦法做到絕對的一致性，這是由CAP理論決定的，緩存系統(tǒng)適用的場景就是非強一致性的場景，所以它屬于CAP中的AP。
所以，我們得委曲求全，可以去做到BASE理論中說的最終一致性。
最終一致性強調的是系統(tǒng)中所有的數(shù)據(jù)副本，在經(jīng)過一段時間的同步后，最終能夠達到一個一致的狀態(tài)。因此，最終一致性的本質是需要系統(tǒng)保證最終數(shù)據(jù)能夠達到一致，而不需要實時保證系統(tǒng)數(shù)據(jù)的強一致性
大佬們給出了到達最終一致性的解決思路，主要是針對上面兩種雙寫策略（先刪緩存，再更新數(shù)據(jù)庫/先更新數(shù)據(jù)庫，再刪緩存）導致的臟數(shù)據(jù)問題，進行相應的處理，來保證最終一致性。
緩存延時雙刪
問：先刪除緩存，再更新數(shù)據(jù)庫中避免臟數(shù)據(jù)？
答案：采用延時雙刪策略。
上文我們提到，在先刪除緩存，再更新數(shù)據(jù)庫的情況下，如果不采用給緩存設置過期時間策略，該數(shù)據(jù)永遠都是臟數(shù)據(jù)。
那么延時雙刪怎么解決這個問題呢？
（1）先淘汰緩存
（2）再寫數(shù)據(jù)庫（這兩步和原來一樣）
（3）休眠1秒，再次淘汰緩存
這么做，可以將1秒內所造成的緩存臟數(shù)據(jù)，再次刪除。
那么，這個1秒怎么確定的，具體該休眠多久呢？
針對上面的情形，讀者應該自行評估自己的項目的讀數(shù)據(jù)業(yè)務邏輯的耗時。然后寫數(shù)據(jù)的休眠時間則在讀數(shù)據(jù)業(yè)務邏輯的耗時基礎上，加幾百ms即可。這么做的目的，就是確保讀請求結束，寫請求可以刪除讀請求造成的緩存臟數(shù)據(jù)。
如果你用了mysql的讀寫分離架構怎么辦？
ok，在這種情況下，造成數(shù)據(jù)不一致的原因如下，還是兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作。
（1）請求A進行寫操作，刪除緩存
（2）請求A將數(shù)據(jù)寫入數(shù)據(jù)庫了，
（3）請求B查詢緩存發(fā)現(xiàn)，緩存沒有值
（4）請求B去從庫查詢，這時，還沒有完成主從同步，因此查詢到的是舊值
（5）請求B將舊值寫入緩存
（6）數(shù)據(jù)庫完成主從同步，從庫變?yōu)樾轮?/p>
上述情形，就是數(shù)據(jù)不一致的原因。還是使用雙刪延時策略。只是，睡眠時間修改為在主從同步的延時時間基礎上，加幾百ms。
采用這種同步淘汰策略，吞吐量降低怎么辦？
ok，那就將第二次刪除作為異步的。自己起一個線程，異步刪除。這樣，寫的請求就不用沉睡一段時間后了，再返回。這么做，加大吞吐量。
所以在先刪除緩存，再更新數(shù)據(jù)庫的情況下，可以使用延時雙刪的策略，來保證臟數(shù)據(jù)只會存活一段時間，就會被準確的數(shù)據(jù)覆蓋。
在先更新數(shù)據(jù)庫，再刪緩存的情況下，緩存出現(xiàn)臟數(shù)據(jù)的情況雖然可能性極小，但也會出現(xiàn)。我們依然可以用延時雙刪策略，在請求A對緩存寫入了臟的舊值之后，再次刪除緩存。來保證去掉臟緩存。
刪緩存失敗了怎么辦：重試機制
看似問題都已經(jīng)解決了，但其實，還有一個問題沒有考慮到，那就是刪除緩存的操作，失敗了怎么辦？比如延時雙刪的時候，第二次緩存刪除失敗了，那不還是沒有清除臟數(shù)據(jù)嗎？
解決方案就是再加上一個重試機制，保證刪除緩存成功。
參考孤獨煙老師給的方案圖：
方案一：
流程如下所示
（1）更新數(shù)據(jù)庫數(shù)據(jù)；
（2）緩存因為種種問題刪除失敗
（3）將需要刪除的key發(fā)送至消息隊列
（4）自己消費消息，獲得需要刪除的key
（5）繼續(xù)重試刪除操作，直到成功
然而，該方案有一個缺點，對業(yè)務線代碼造成大量的侵入。于是有了方案二，在方案二中，啟動一個訂閱程序去訂閱數(shù)據(jù)庫的binlog，獲得需要操作的數(shù)據(jù)。在應用程序中，另起一段程序，獲得這個訂閱程序傳來的信息，進行刪除緩存操作。
方案二：
流程如下圖所示：
（1）更新數(shù)據(jù)庫數(shù)據(jù)
（2）數(shù)據(jù)庫會將操作信息寫入binlog日志當中
（3）訂閱程序提取出所需要的數(shù)據(jù)以及key
（4）另起一段非業(yè)務代碼，獲得該信息
（5）嘗試刪除緩存操作，發(fā)現(xiàn)刪除失敗
（6）將這些信息發(fā)送至消息隊列
（7）重新從消息隊列中獲得該數(shù)據(jù)，重試操作。
而讀取binlog的中間件，可以采用阿里開源的canal
好了，到這里我們已經(jīng)把緩存雙寫一致性的思路徹底梳理了一遍，下面就是我對這幾種思路徒手寫的實戰(zhàn)代碼，方便有需要的朋友參考。
緩存和數(shù)據(jù)庫一致性實戰(zhàn)
實戰(zhàn)：先刪除緩存，再更新數(shù)據(jù)庫
終于到了實戰(zhàn)，我們在秒殺項目的代碼上增加接口：先刪除緩存，再更新數(shù)據(jù)庫
OrderController中新增：
/***?下單接口：先刪除緩存，再更新數(shù)據(jù)庫*?@param?sid*?@return*/ @RequestMapping("/createOrderWithCacheV1/{sid}") @ResponseBody public?String?createOrderWithCacheV1(@PathVariable?int?sid)?{int?count?=?0;try?{//?刪除庫存緩存stockService.delStockCountCache(sid);//?完成扣庫存下單事務orderService.createPessimisticOrder(sid);}?catch?(Exception?e)?{LOGGER.error("購買失敗：[{}]",?e.getMessage());return?"購買失敗，庫存不足";}LOGGER.info("購買成功，剩余庫存為:?[{}]",?count);return?String.format("購買成功，剩余庫存為：%d",?count); }stockService中新增：
@Override public?void?delStockCountCache(int?id)?{String?hashKey?=?CacheKey.STOCK_COUNT.getKey()?+?"_"?+?id;stringRedisTemplate.delete(hashKey);LOGGER.info("刪除商品id：[{}]?緩存",?id); }其他涉及的代碼都在之前三篇文章中有介紹，并且可以直接去Github拿到項目源碼，就不在這里重復貼了。
實戰(zhàn)：先更新數(shù)據(jù)庫，再刪緩存
如果是先更新數(shù)據(jù)庫，再刪緩存，那么代碼只是在業(yè)務順序上顛倒了一下，這里就只貼OrderController中新增：
/***?下單接口：先更新數(shù)據(jù)庫，再刪緩存*?@param?sid*?@return*/ @RequestMapping("/createOrderWithCacheV2/{sid}") @ResponseBody public?String?createOrderWithCacheV2(@PathVariable?int?sid)?{int?count?=?0;try?{//?完成扣庫存下單事務orderService.createPessimisticOrder(sid);//?刪除庫存緩存stockService.delStockCountCache(sid);}?catch?(Exception?e)?{LOGGER.error("購買失敗：[{}]",?e.getMessage());return?"購買失敗，庫存不足";}LOGGER.info("購買成功，剩余庫存為:?[{}]",?count);return?String.format("購買成功，剩余庫存為：%d",?count); }實戰(zhàn)：緩存延時雙刪
如何做延時雙刪呢，最好的方法是開設一個線程池，在線程中刪除key，而不是使用Thread.sleep進行等待，這樣會阻塞用戶的請求。
更新前先刪除緩存，然后更新數(shù)據(jù)，再延時刪除緩存。
OrderController中新增接口：
//?延時時間：預估讀數(shù)據(jù)庫數(shù)據(jù)業(yè)務邏輯的耗時，用來做緩存再刪除 private?static?final?int?DELAY_MILLSECONDS?=?1000;/***?下單接口：先刪除緩存，再更新數(shù)據(jù)庫，緩存延時雙刪*?@param?sid*?@return*/ @RequestMapping("/createOrderWithCacheV3/{sid}") @ResponseBody public?String?createOrderWithCacheV3(@PathVariable?int?sid)?{int?count;try?{//?刪除庫存緩存stockService.delStockCountCache(sid);//?完成扣庫存下單事務count?=?orderService.createPessimisticOrder(sid);//?延時指定時間后再次刪除緩存cachedThreadPool.execute(new?delCacheByThread(sid));}?catch?(Exception?e)?{LOGGER.error("購買失敗：[{}]",?e.getMessage());return?"購買失敗，庫存不足";}LOGGER.info("購買成功，剩余庫存為:?[{}]",?count);return?String.format("購買成功，剩余庫存為：%d",?count); }OrderController中新增線程池：
//?延時雙刪線程池 private?static?ExecutorService?cachedThreadPool?=?new?ThreadPoolExecutor(0,?Integer.MAX_VALUE,?60L,?TimeUnit.SECONDS,new?SynchronousQueue<Runnable>());/***?緩存再刪除線程*/ private?class?delCacheByThread?implements?Runnable?{private?int?sid;public?delCacheByThread(int?sid)?{this.sid?=?sid;}public?void?run()?{try?{LOGGER.info("異步執(zhí)行緩存再刪除，商品id：[{}]，?首先休眠：[{}]?毫秒",?sid,?DELAY_MILLSECONDS);Thread.sleep(DELAY_MILLSECONDS);stockService.delStockCountCache(sid);LOGGER.info("再次刪除商品id：[{}]?緩存",?sid);}?catch?(Exception?e)?{LOGGER.error("delCacheByThread執(zhí)行出錯",?e);}} }來試驗一下，請求接口createOrderWithCacheV3：
日志中，做到了兩次刪除：
實戰(zhàn)：刪除緩存重試機制
上文提到了，要解決刪除失敗的問題，需要用到消息隊列，進行刪除操作的重試。這里我們?yōu)榱诉_到效果，接入了RabbitMq，并且需要在接口中寫發(fā)送消息，并且需要消費者常駐來消費消息。Spring整合RabbitMq還是比較簡單的，我把簡單的整合代碼也貼出來。
pom.xml新增RabbitMq的依賴：
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-amqp</artifactId> </dependency>寫一個RabbitMqConfig：
@Configuration public?class?RabbitMqConfig?{@Beanpublic?Queue?delCacheQueue()?{return?new?Queue("delCache");}}添加一個消費者：
@Component @RabbitListener(queues?=?"delCache") public?class?DelCacheReceiver?{private?static?final?Logger?LOGGER?=?LoggerFactory.getLogger(DelCacheReceiver.class);@Autowiredprivate?StockService?stockService;@RabbitHandlerpublic?void?process(String?message)?{LOGGER.info("DelCacheReceiver收到消息:?"?+?message);LOGGER.info("DelCacheReceiver開始刪除緩存:?"?+?message);stockService.delStockCountCache(Integer.parseInt(message));} }OrderController中新增接口：
/***?下單接口：先更新數(shù)據(jù)庫，再刪緩存，刪除緩存重試機制*?@param?sid*?@return*/ @RequestMapping("/createOrderWithCacheV4/{sid}") @ResponseBody public?String?createOrderWithCacheV4(@PathVariable?int?sid)?{int?count;try?{//?完成扣庫存下單事務count?=?orderService.createPessimisticOrder(sid);//?刪除庫存緩存stockService.delStockCountCache(sid);//?延時指定時間后再次刪除緩存//?cachedThreadPool.execute(new?delCacheByThread(sid));//?假設上述再次刪除緩存沒成功，通知消息隊列進行刪除緩存sendDelCache(String.valueOf(sid));}?catch?(Exception?e)?{LOGGER.error("購買失敗：[{}]",?e.getMessage());return?"購買失敗，庫存不足";}LOGGER.info("購買成功，剩余庫存為:?[{}]",?count);return?String.format("購買成功，剩余庫存為：%d",?count); }訪問createOrderWithCacheV4：
可以看到，我們先完成了下單，然后刪除了緩存，并且假設延遲刪除緩存失敗了，發(fā)送給消息隊列重試的消息，消息隊列收到消息后再去刪除緩存。
實戰(zhàn)：讀取binlog異步刪除緩存
我們需要用到阿里開源的canal來讀取binlog進行緩存的異步刪除。
我寫了一篇Canal的入門文章，其中用的入門例子就是讀取binlog刪除緩存。大家可以直接跳轉到這里：阿里開源MySQL中間件Canal快速入門
擴展閱讀
更新緩存的的Design Pattern有四種：
Cache aside
Read through
Write through
Write behind caching，這里有陳皓的總結文章可以進行學習。
https://coolshell.cn/articles/17416.html
小結
引用陳浩《緩存更新的套路》最后的總結語作為小結：
分布式系統(tǒng)里要么通過2PC或是Paxos協(xié)議保證一致性，要么就是拼命的降低并發(fā)時臟數(shù)據(jù)的概率
緩存系統(tǒng)適用的場景就是非強一致性的場景，所以它屬于CAP中的AP，BASE理論。
異構數(shù)據(jù)庫本來就沒辦法強一致，只是盡可能減少時間窗口，達到最終一致性。
還有別忘了設置過期時間，這是個兜底方案
結束語
本文總結并探討了緩存數(shù)據(jù)庫雙寫一致性問題。
文章內容大致可以總結為如下幾點：
對于讀多寫少的數(shù)據(jù)，請使用緩存。
為了保持數(shù)據(jù)庫和緩存的一致性，會導致系統(tǒng)吞吐量的下降。
為了保持數(shù)據(jù)庫和緩存的一致性，會導致業(yè)務代碼邏輯復雜。
緩存做不到絕對一致性，但可以做到最終一致性。
對于需要保證緩存數(shù)據(jù)庫數(shù)據(jù)一致的情況，請盡量考慮對一致性到底有多高要求，選定合適的方案，避免過度設計。
作者水平有限，寫文章過程中難免出現(xiàn)錯誤和疏漏，請理性討論與指正。
參考
https://cloud.tencent.com/developer/article/1574827
https://www.jianshu.com/p/2936a5c65e6b
https://www.cnblogs.com/rjzheng/p/9041659.html
https://www.cnblogs.com/codeon/p/8287563.html
https://www.jianshu.com/p/0275ecca2438
https://www.jianshu.com/p/dc1e5091a0d8
https://coolshell.cn/articles/17416.html
如果文章對你有幫助，不妨點贊，收藏起來~
往期推薦磊哥工作十幾年了，竟沒有用過do-while！（文末送書）
2020-09-06
3種時間格式化的方法，SpringBoot篇！
2020-09-04
多圖證明，Java到底是值傳遞還是引用傳遞？
2020-09-02
阿里為什么推薦使用LongAdder，而不是volatile？
2020-08-25
關注下方二維碼，收獲更多干貨！
總結
以上是生活随笔為你收集整理的两难！先更新数据库再删缓存？还是先删缓存再更新数据库？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 面试官 | 什么是 Lambda？该如何
- 下一篇： 逻辑性最强的React Native环境