快取與資料庫一致性問題深度剖析

後端技術漫談發表於2020-09-04

前言

本篇文章是我之前系列文章中的一篇,主要討論了我們在平時的開發過程中,各大系統中都要用到的快取資料的問題,進一步延伸到資料庫和快取的雙寫一致性問題,並且給出了所有方案的實現程式碼方便大家參考。

本篇文章主要內容

  • 資料快取
    • 為何要使用快取
    • 哪類資料適合快取
    • 快取的利與弊
  • 如何保證快取和資料庫一致性
    • 不更新快取,而是刪除快取
    • 先操作快取,還是先運算元據庫
    • 非要保證資料庫和快取資料強一致該怎麼辦
  • 快取和資料庫一致性實戰
    • 實戰:先刪除快取,再更新資料庫
    • 實戰:先更新資料庫,再刪快取
    • 實戰:快取延時雙刪
    • 實戰:刪除快取重試機制
    • 實戰:讀取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理論。

異構資料庫本來就沒辦法強一致,只是儘可能減少時間視窗,達到最終一致性

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

結束語

本文總結並探討了快取資料庫雙寫一致性問題。

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

  • 對於讀多寫少的資料,請使用快取。
  • 為了保持資料庫和快取的一致性,會導致系統吞吐量的下降。
  • 為了保持資料庫和快取的一致性,會導致業務程式碼邏輯複雜。
  • 快取做不到絕對一致性,但可以做到最終一致性。
  • 對於需要保證快取資料庫資料一致的情況,請儘量考慮對一致性到底有多高要求,選定合適的方案,避免過度設計。

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

碼字不易,只求關注,歡迎關注我的原創技術公眾號:後端技術漫談(二維碼見文章底部)

參考

關注我

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

各大平臺都可以找到我

原創文章主要內容

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

個人公眾號:後端技術漫談

如果文章對你有幫助,不妨點贊,收藏起來~

相關文章