緩存與數據庫一致性問題深度剖析 （修訂）

時間  2020-10-17
標籤 html mysql git github web 面試 redis 算法 spring sql 欄目 SQL 简体版
原文   原文鏈接

前言

當咱們在作數據庫與緩存數據同步時，究竟更新緩存，仍是刪除緩存，到底是先操做數據庫，仍是先操做緩存？本文帶你們深度分析數據庫與緩存的雙寫問題，而且給出了全部方案的實現代碼方便你們參考。html

本篇文章主要內容

  • 數據緩存
    • 爲什麼要使用緩存
    • 哪類數據適合緩存
    • 緩存的利與弊
  • 如何保證緩存和數據庫一致性
    • 不更新緩存，而是刪除緩存
    • 先操做緩存，仍是先操做數據庫
    • 非要保證數據庫和緩存數據強一致該怎麼辦
  • 緩存和數據庫一致性實戰
    • 實戰：先刪除緩存，再更新數據庫
    • 實戰：先更新數據庫，再刪緩存
    • 實戰：緩存延時雙刪
    • 實戰：刪除緩存重試機制
    • 實戰：讀取binlog異步刪除緩存

碼字不易，只求關注，歡迎關注個人原創技術公衆號：後端技術漫談（二維碼見文章底部）mysql

項目源碼在這裏

https://github.com/qqxx6661/miaoshagit

數據緩存

在咱們實際的業務場景中，必定有不少須要作數據緩存的場景，好比售賣商品的頁面，包括了許多併發訪問量很大的數據，它們能夠稱做是是「熱點」數據，這些數據有一個特色，就是更新頻率低，讀取頻率高，這些數據應該儘可能被緩存，從而減小請求打到數據庫上的機會，減輕數據庫的壓力。github

爲什麼要使用緩存

緩存是爲了追求「快」而存在的。咱們用代碼舉一個例子。web

我在本身的Demo代碼倉庫中增長了兩個查詢庫存的接口getStockByDB和getStockByCache，分別表示從數據庫和緩存查詢某商品的庫存量。面試

隨後咱們用JMeter進行併發請求測試。（JMeter的使用請參考我以前寫的文章：點擊這裏）redis

須要聲明的是，個人測試並不嚴謹，只是做對比測試，不要做爲實際服務性能的參考。算法

這是兩個接口的代碼：spring

/**
 * 查詢庫存：經過數據庫查詢庫存
 * @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);
}

/**
 * 查詢庫存：經過緩存查詢庫存
 * 緩存命中：返回庫存
 * 緩存未命中：查詢數據庫寫入緩存並返回
 * @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("緩存未命中，查詢數據庫，並寫入緩存");
            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個併發請求的狀況下，運行JMeter，結果首先出現了大量的報錯，10000個請求中98%的請求都直接失敗了。讓人很慌張~sql

打開日誌，報錯以下：

SpringBoot內置的Tomcat最大併發數搞的鬼，其默認值爲200，對於10000的併發，單機服務實在是力不從心。固然，你能夠修改這裏的併發數設置，可是你的小機器仍然可能會扛不住。

將其修改成以下配置後，個人小機器纔在經過緩存拿庫存的狀況下，保證了10000個併發的100%返回請求：

server.tomcat.max-threads=10000
server.tomcat.max-connections=10000

能夠看到，不使用緩存的狀況下，吞吐量爲668個請求每秒：

使用緩存的狀況下，吞吐量爲2177個請求每秒：

在這種「十分不嚴謹」的對比下，有緩存對於一臺單機，性能提高了3倍多，若是在多臺機器，更多併發的狀況下，因爲數據庫有了更大的壓力，緩存的性能優點應該會更加明顯。

測完了這個小實驗，我看了眼我掛着MySql的小水管騰訊雲服務器，生怕他被這麼高流量搞掛。這種突發的流量，指不定會被檢測爲異常攻擊流量呢~

我用的是騰訊雲服務器1C4G2M，活動買的，很便宜。這裏打個免費的廣告，請騰訊雲看到後聯繫我給我打錢 ;)

哪類數據適合緩存

緩存量大但又不常變化的數據，好比詳情，評論等。對於那些常常變化的數據，其實並不適合緩存，一方面會增長系統的複雜性（緩存的更新，緩存髒數據），另外一方面也給系統帶來必定的不穩定性（緩存系統的維護）。

但一些極端狀況下，你須要將一些會變更的數據進行緩存，好比想要頁面顯示準實時的庫存數，或者其餘一些特殊業務場景。這時候你須要保證緩存不能（一直）有髒數據，這就須要再深刻討論一下。

緩存的利與弊

咱們到底該不應上緩存的，這其實也是個trade-off（權衡）的問題。

上緩存的優勢：

  • 可以縮短服務的響應時間，給用戶帶來更好的體驗。
  • 可以增大系統的吞吐量，依然可以提高用戶體驗。
  • 減輕數據庫的壓力，防止高峯期數據庫被壓垮，致使整個線上服務BOOM！

上了緩存，也會引入不少額外的問題：

  • 緩存有多種選型，是內存緩存，memcached仍是redis，你是否都熟悉，若是不熟悉，無疑增長了維護的難度（原本是個純潔的數據庫系統）。
  • 緩存系統也要考慮分佈式，好比redis的分佈式緩存還會有不少坑，無疑增長了系統的複雜性。
  • 在特殊場景下，若是對緩存的準確性有很是高的要求，就必須考慮 緩存和數據庫的一致性問題。

本文想要重點討論的，就是緩存和數據庫的一致性問題，各位看官且往下看。

如何保證緩存和數據庫一致性

說了這麼多緩存的必要性，那麼使用緩存是否是就是一個很簡單的事情了呢，我以前也一直是這麼以爲的，直到遇到了須要緩存與數據庫保持強一致的場景，才知道讓數據庫數據和緩存數據保持一致性是一門很高深的學問。

從遠古的硬件緩存，操做系統緩存開始，緩存就是一門獨特的學問。這個問題也被業界探討了很是久，爭論至今。我翻閱了不少資料，發現其實這是一個權衡的問題。值得好好講講。

如下的討論會引入幾方觀點，我會跟着觀點來寫代碼驗證所提到的問題。

不更新緩存，而是刪除緩存

大部分觀點認爲，作緩存不該該是去更新緩存，而是應該刪除緩存，而後由下個請求去去緩存，發現不存在後再讀取數據庫，寫入緩存。

觀點引用：《分佈式之數據庫和緩存雙寫一致性方案解析》孤獨煙

緣由一：線程安全角度

同時有請求A和請求B進行更新操做，那麼會出現

（1）線程A更新了數據庫

（2）線程B更新了數據庫

（3）線程B更新了緩存

（4）線程A更新了緩存

這就出現請求A更新緩存應該比請求B更新緩存早纔對，可是由於網絡等緣由，B卻比A更早更新了緩存。這就致使了髒數據，所以不考慮。

緣由二：業務場景角度

有以下兩點：

（1）若是你是一個寫數據庫場景比較多，而讀數據場景比較少的業務需求，採用這種方案就會致使，數據壓根還沒讀到，緩存就被頻繁的更新，浪費性能。

（2）若是你寫入數據庫的值，並非直接寫入緩存的，而是要通過一系列複雜的計算再寫入緩存。那麼，每次寫入數據庫後，都再次計算寫入緩存的值，無疑是浪費性能的。顯然，刪除緩存更爲適合。

其實若是業務很是簡單，只是去數據庫拿一個值，寫入緩存，那麼更新緩存也是能夠的。可是，淘汰緩存操做簡單，而且帶來的反作用只是增長了一次cache miss，建議做爲通用的處理方式。

先操做緩存，仍是先操做數據庫

那麼問題就來了，咱們是先刪除緩存，而後再更新數據庫，仍是先更新數據庫，再刪緩存呢？

先來看看大佬們怎麼說。

《【58沈劍架構系列】緩存架構設計細節二三事》58沈劍：

對於一個不能保證事務性的操做，必定涉及「哪一個任務先作，哪一個任務後作」的問題，解決這個問題的方向是：若是出現不一致，誰先作對業務的影響較小，就誰先執行。

假設先淘汰緩存，再寫數據庫：第一步淘汰緩存成功，第二步寫數據庫失敗，則只會引起一次Cache miss。

假設先寫數據庫，再淘汰緩存：第一步寫數據庫操做成功，第二步淘汰緩存失敗，則會出現DB中是新數據，Cache中是舊數據，數據不一致。

沈劍老師說的沒有問題，不過沒徹底考慮好併發請求時的數據髒讀問題，讓咱們再來看看孤獨煙老師《分佈式之數據庫和緩存雙寫一致性方案解析》：

先刪緩存，再更新數據庫

該方案會致使請求數據不一致

同時有一個請求A進行更新操做，另外一個請求B進行查詢操做。那麼會出現以下情形:

（1）請求A進行寫操做，刪除緩存

（2）請求B查詢發現緩存不存在

（3）請求B去數據庫查詢獲得舊值

（4）請求B將舊值寫入緩存

（5）請求A將新值寫入數據庫

上述狀況就會致使不一致的情形出現。並且，若是不採用給緩存設置過時時間策略，該數據永遠都是髒數據。

因此先刪緩存，再更新數據庫並非一勞永逸的解決方案，再看看先更新數據庫，再刪緩存這種方案怎麼樣？

先更新數據庫，再刪緩存這種狀況不存在併發問題麼？

不是的。假設這會有兩個請求，一個請求A作查詢操做，一個請求B作更新操做，那麼會有以下情形產生

（1）緩存恰好失效

（2）請求A查詢數據庫，得一箇舊值

（3）請求B將新值寫入數據庫

（4）請求B刪除緩存

（5）請求A將查到的舊值寫入緩存

ok，若是發生上述狀況，確實是會發生髒數據。

然而，發生這種狀況的機率又有多少呢？

發生上述狀況有一個先天性條件，就是步驟（3）的寫數據庫操做比步驟（2）的讀數據庫操做耗時更短，纔有可能使得步驟（4）先於步驟（5）。但是，你們想一想，數據庫的讀操做的速度遠快於寫操做的（否則作讀寫分離幹嗎，作讀寫分離的意義就是由於讀操做比較快，耗資源少），所以步驟（3）耗時比步驟（2）更短，這一情形很難出現。

先更新數據庫，再刪緩存依然會有問題，不過，問題出現的可能性會由於上面說的緣由，變得比較低！

因此，若是你想實現基礎的緩存數據庫雙寫一致的邏輯，那麼在大多數狀況下，在不想作過多設計，增長太大工做量的狀況下，請先更新數據庫，再刪緩存!

我非要數據庫和緩存數據強一致怎麼辦

那麼，若是我非要保證絕對一致性怎麼辦，先給出結論：

沒有辦法作到絕對的一致性，這是由CAP理論決定的，緩存系統適用的場景就是非強一致性的場景，因此它屬於CAP中的AP。

因此，咱們得委曲求全，能夠去作到BASE理論中說的最終一致性。

最終一致性強調的是系統中全部的數據副本，在通過一段時間的同步後，最終可以達到一個一致的狀態。所以，最終一致性的本質是須要系統保證最終數據可以達到一致，而不須要實時保證系統數據的強一致性

大佬們給出了到達最終一致性的解決思路，主要是針對上面兩種雙寫策略（先刪緩存，再更新數據庫/先更新數據庫，再刪緩存）致使的髒數據問題，進行相應的處理，來保證最終一致性。

緩存延時雙刪

問：先刪除緩存，再更新數據庫中避免髒數據？

答案：採用延時雙刪策略。

上文咱們提到，在先刪除緩存，再更新數據庫的狀況下，若是不採用給緩存設置過時時間策略，該數據永遠都是髒數據。

那麼延時雙刪怎麼解決這個問題呢？

（1）先淘汰緩存

（2）再寫數據庫（這兩步和原來同樣）

（3）休眠1秒，再次淘汰緩存

這麼作，能夠將1秒內所形成的緩存髒數據，再次刪除。

那麼，這個1秒怎麼肯定的，具體該休眠多久呢？

針對上面的情形，讀者應該自行評估本身的項目的讀數據業務邏輯的耗時。而後寫數據的休眠時間則在讀數據業務邏輯的耗時基礎上，加幾百ms便可。這麼作的目的，就是確保讀請求結束，寫請求能夠刪除讀請求形成的緩存髒數據。

若是你用了mysql的讀寫分離架構怎麼辦？

ok，在這種狀況下，形成數據不一致的緣由以下，仍是兩個請求，一個請求A進行更新操做，另外一個請求B進行查詢操做。

（1）請求A進行寫操做，刪除緩存

（2）請求A將數據寫入數據庫了，

（3）請求B查詢緩存發現，緩存沒有值

（4）請求B去從庫查詢，這時，尚未完成主從同步，所以查詢到的是舊值

（5）請求B將舊值寫入緩存

（6）數據庫完成主從同步，從庫變爲新值

上述情形，就是數據不一致的緣由。仍是使用雙刪延時策略。只是，睡眠時間修改成在主從同步的延時時間基礎上，加幾百ms。

採用這種同步淘汰策略，吞吐量下降怎麼辦？

ok，那就將第二次刪除做爲異步的。本身起一個線程，異步刪除。這樣，寫的請求就不用沉睡一段時間後了，再返回。這麼作，加大吞吐量。

因此在先刪除緩存，再更新數據庫的狀況下，可使用延時雙刪的策略，來保證髒數據只會存活一段時間，就會被準確的數據覆蓋。

在先更新數據庫，再刪緩存的狀況下，緩存出現髒數據的狀況雖然可能性極小，但也會出現。咱們依然能夠用延時雙刪策略，在請求A對緩存寫入了髒的舊值以後，再次刪除緩存。來保證去掉髒緩存。

刪緩存失敗了怎麼辦：重試機制

看似問題都已經解決了，但其實，還有一個問題沒有考慮到，那就是刪除緩存的操做，失敗了怎麼辦？好比延時雙刪的時候，第二次緩存刪除失敗了，那不仍是沒有清除髒數據嗎？

解決方案就是再加上一個重試機制，保證刪除緩存成功。

參考孤獨煙老師給的方案圖：

方案一：

流程以下所示

（1）更新數據庫數據；

（2）緩存由於種種問題刪除失敗

（3）將須要刪除的key發送至消息隊列

（4）本身消費消息，得到須要刪除的key

（5）繼續重試刪除操做，直到成功

然而，該方案有一個缺點，對業務線代碼形成大量的侵入。因而有了方案二，在方案二中，啓動一個訂閱程序去訂閱數據庫的binlog，得到須要操做的數據。在應用程序中，另起一段程序，得到這個訂閱程序傳來的信息，進行刪除緩存操做。

方案二：

流程以下圖所示：

（1）更新數據庫數據

（2）數據庫會將操做信息寫入binlog日誌當中

（3）訂閱程序提取出所須要的數據以及key

（4）另起一段非業務代碼，得到該信息

（5）嘗試刪除緩存操做，發現刪除失敗

（6）將這些信息發送至消息隊列

（7）從新從消息隊列中得到該數據，重試操做。

而讀取binlog的中間件，能夠採用阿里開源的canal

好了，到這裏咱們已經把緩存雙寫一致性的思路完全梳理了一遍，下面就是我對這幾種思路徒手寫的實戰代碼，方便有須要的朋友參考。

緩存和數據庫一致性實戰

實戰：先刪除緩存，再更新數據庫

終於到了實戰，咱們在秒殺項目的代碼上增長接口：先刪除緩存，再更新數據庫

OrderController中新增：

/**
 * 下單接口：先刪除緩存，再更新數據庫
 * @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拿到項目源碼，就不在這裏重複貼了。

實戰：先更新數據庫，再刪緩存

若是是先更新數據庫，再刪緩存，那麼代碼只是在業務順序上顛倒了一下，這裏就只貼OrderController中新增：

/**
 * 下單接口：先更新數據庫，再刪緩存
 * @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);
}

實戰：緩存延時雙刪

如何作延時雙刪呢，最好的方法是開設一個線程池，在線程中刪除key，而不是使用Thread.sleep進行等待，這樣會阻塞用戶的請求。

更新前先刪除緩存，而後更新數據，再延時刪除緩存。

OrderController中新增接口：


// 延時時間：預估讀數據庫數據業務邏輯的耗時，用來作緩存再刪除
private static final int DELAY_MILLSECONDS = 1000;


/**
 * 下單接口：先刪除緩存，再更新數據庫，緩存延時雙刪
 * @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("異步執行緩存再刪除，商品id：[{}]， 首先休眠：[{}] 毫秒", sid, DELAY_MILLSECONDS);
            Thread.sleep(DELAY_MILLSECONDS);
            stockService.delStockCountCache(sid);
            LOGGER.info("再次刪除商品id：[{}] 緩存", sid);
        } catch (Exception e) {
            LOGGER.error("delCacheByThread執行出錯", e);
        }
    }
}

來試驗一下，請求接口createOrderWithCacheV3：

日誌中，作到了兩次刪除：

實戰：刪除緩存重試機制

上文提到了，要解決刪除失敗的問題，須要用到消息隊列，進行刪除操做的重試。這裏咱們爲了達到效果，接入了RabbitMq，而且須要在接口中寫發送消息，而且須要消費者常駐來消費消息。Spring整合RabbitMq仍是比較簡單的，我把簡單的整合代碼也貼出來。

pom.xml新增RabbitMq的依賴：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

寫一個RabbitMqConfig：

@Configuration
public class RabbitMqConfig {

    @Bean
    public Queue delCacheQueue() {
        return new Queue("delCache");
    }

}

添加一個消費者：

@Component
@RabbitListener(queues = "delCache")
public class DelCacheReceiver {

    private static final Logger LOGGER = LoggerFactory.getLogger(DelCacheReceiver.class);

    @Autowired
    private StockService stockService;

    @RabbitHandler
    public void process(String message) {
        LOGGER.info("DelCacheReceiver收到消息: " + message);
        LOGGER.info("DelCacheReceiver開始刪除緩存: " + message);
        stockService.delStockCountCache(Integer.parseInt(message));
    }
}

OrderController中新增接口：

/**
 * 下單接口：先更新數據庫，再刪緩存，刪除緩存重試機制
 * @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：

能夠看到，咱們先完成了下單，而後刪除了緩存，而且假設延遲刪除緩存失敗了，發送給消息隊列重試的消息，消息隊列收到消息後再去刪除緩存。

實戰：讀取binlog異步刪除緩存

咱們須要用到阿里開源的canal來讀取binlog進行緩存的異步刪除。

我寫了一篇Canal的入門文章，其中用的入門例子就是讀取binlog刪除緩存。你們能夠直接跳轉到這裏：阿里開源MySQL中間件Canal快速入門

擴展閱讀

更新緩存的的Design Pattern有四種：

  • Cache aside
  • Read through
  • Write through
  • Write behind caching，這裏有陳皓的總結文章能夠進行學習。

https://coolshell.cn/articles/17416.html

小結

引用陳浩《緩存更新的套路》最後的總結語做爲小結：

分佈式系統裏要麼經過2PC或是Paxos協議保證一致性，要麼就是拼命的下降併發時髒數據的機率

緩存系統適用的場景就是非強一致性的場景，因此它屬於CAP中的AP，BASE理論。

異構數據庫原本就沒辦法強一致，只是儘量減小時間窗口，達到最終一致性。

還有別忘了設置過時時間，這是個兜底方案

結束語

本文總結並探討了緩存數據庫雙寫一致性問題。

文章內容大體能夠總結爲以下幾點：

  • 對於讀多寫少的數據，請使用緩存。
  • 爲了保持數據庫和緩存的一致性，會致使系統吞吐量的降低。
  • 爲了保持數據庫和緩存的一致性，會致使業務代碼邏輯複雜。
  • 緩存作不到絕對一致性，但能夠作到最終一致性。
  • 對於須要保證緩存數據庫數據一致的狀況，請儘可能考慮對一致性到底有多高要求，選定合適的方案，避免過分設計。

做者水平有限，寫文章過程當中不免出現錯誤和疏漏，請理性討論與指正。

碼字不易，只求關注，歡迎關注個人原創技術公衆號：後端技術漫談（二維碼見文章底部）

參考

  • 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

關注我

我是一名後端開發工程師。主要關注後端開發，數據安全，爬蟲，物聯網，邊緣計算等方向，歡迎交流。

各大平臺均可以找到我

  • 微信公衆號：後端技術漫談
  • Github：@qqxx6661
  • CSDN：@蠻三刀把刀
  • 知乎：@後端技術漫談
  • 簡書：@蠻三刀把刀
  • 掘金：@蠻三刀把刀
  • 騰訊雲+社區：@後端技術漫談

原創文章主要內容

  • 後端開發實戰
  • Java面試知識
  • 設計模式/數據結構/算法題解
  • 讀書筆記/逸聞趣事/程序人生

我的公衆號：後端技術漫談

我的公衆號：後端技術漫談

若是文章對你有幫助，不妨點贊，收藏起來~

本文分享自微信公衆號 - 後端技術漫談（Rude3Knife）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程