[[340660]]

前言

當我們在做數據庫與緩存數據同步時，究竟更新緩存，還是刪除緩存，究竟是先操作數據庫，還是先操作緩存?本文帶大家深度分析數據庫與緩存的雙寫問題，并且給出了所有方案的實現代碼方便大家參考。

本篇文章主要內容

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

項目源碼在這里

https://github.com/qqxx6661/miaosha

數據緩存

在我們實際的業務場景中，一定有很多需要做數據緩存的場景，比如售賣商品的頁面，包括了許多并發訪問量很大的數據，它們可以稱作是是“熱點”數據，這些數據有一個特點，就是更新頻率低，讀取頻率高，這些數據應該盡量被緩存，從而減少請求打到數據庫上的機會，減輕數據庫的壓力。

為何要使用緩存

緩存是為了追求“快”而存在的。我們用代碼舉一個例子。

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

隨后我們用JMeter進行并發請求測試。(JMeter的使用請參考我之前寫的文章：點擊這里)

需要聲明的是，我的測試并不嚴謹，只是作對比測試，不要作為實際服務性能的參考。

這是兩個接口的代碼：

/** 
 * 查詢庫存：通過數據庫查詢庫存 
 * @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%的請求都直接失敗了。讓人很慌張~

打開日志，報錯如下：

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理論。

異構數據庫本來就沒辦法強一致，只是盡可能減少時間窗口，達到最終一致性。

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

結束語

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

文章內容大致可以總結為如下幾點：

• 對于讀多寫少的數據，請使用緩存。
• 為了保持數據庫和緩存的一致性，會導致系統吞吐量的下降。
• 為了保持數據庫和緩存的一致性，會導致業務代碼邏輯復雜。
• 緩存做不到絕對一致性，但可以做到最終一致性。
• 對于需要保證緩存數據庫數據一致的情況，請盡量考慮對一致性到底有多高要求，選定合適的方案，避免過度設計。

本文轉載自微信公眾號「后端技術漫談」，可以通過以下二維碼關注。轉載本文請聯系后端技術漫談公眾號。