快取把我坑慘了..

程序员老猫發表於2024-03-14
快取

故事

春天，辦公室外的世界總是讓人神往的，小貓帶著耳機，託著腮幫，望著外面美好的春光神遊著...

一聲不和諧的座機電話聲打破這份本該屬於小貓的寧靜，“hi，小貓，線上有個客戶想購買A產品規格的商品，投訴說下單總是失敗，幫忙看一下啥原因。”客服部小姐姐甜美的聲音從電話那頭傳來。“哦哦，好，我看一下，把商品編號發一下吧......”

由於前一段時間的系統熟悉，小貓對現在的資料表模型已經瞭然於胸，當下就直接定位到了商品規格資訊表，發現資料庫中客戶想購買的規格已經被下架了，但是前端的快取好像並沒有被重新整理。

小貓在系統中找到了之前開發人員留的後門介面，直接curl語句重新重新整理了一下介面，快取問題搞定了。

關於商品快取和資料庫不一致的情況，其實小貓一週會遇到好幾個這樣的客訴，他深受DB以及快取不一致的苦，於是他下定決心想要從根本上解決問題，而不是curl呼叫後門介面......

寫在前面

小貓的態度其實還是相當值得肯定的，當他下定決心從根本上排查問題的時候開始，小貓其實就是一名合格而且負責的研發，這也是我們每一位軟體研發人員所需要具備的處理事情的態度。

在軟體系統演進的過程中，只有我們在修復歷史遺留的問題的時候，才是真正意義上地對系統進行了維護，如果我們使用一些極端的手段(例如上述提到的後門介面curl語句)來保持古老而陳腐的程式碼繼續工作的時候，這其實是一種苟且。一旦系統有了問題，我們其實就需要及時進行最佳化修復，否則會形成不好的示範，更多的後來者傾向於類似的方式解決問題，這也是為什麼FixController存在的原因，這其實就是系統腐化的標誌。

言歸正傳，關於快取和DB不一致相信大家在日常開發的過程中都有遇到過，那麼我們接下來就和大家好好盤一盤，快取和DB不一致的時候，咱們是如何去解決的。接下來，大家會看到解決方案以及實戰。
快取概要

常規介面快取讀取更新

常規快取讀取

看到上面的圖，我們可以清晰地知道快取在實際場景中的工作原理。

  1. 發生請求的時候，優先讀取快取，如果命中快取則返回結果集。
  2. 如果快取沒有命中，則迴歸資料庫查詢。
  3. 將資料庫查詢得到的結果集再次同步到快取中，並且返回對應的結果集。

這是大家比較熟悉的快取使用方式，可以有效減輕資料庫壓力，提升介面訪問效能。但是在這樣的一個架構中，會有一個問題，就是一份資料同時儲存在資料庫和快取中，如果資料發生變化，需要同時更新快取和資料庫，由於更新是有先後順序的，並且它不像資料庫中多表事務操作滿足ACID特性，所以這樣就會出現資料一致性的問題。

DB和快取不一致方案與實戰DEMO

關於快取和DB不一致，其實無非就是以下四種解決方案：

  1. 先更新快取，再更新資料庫
  2. 先更新資料庫，再更新快取
  3. 先刪除快取，後更新資料庫
  4. 先更新資料庫，後刪除快取

先更新快取，再更新資料庫(不建議)

更新快取後更新資料庫

這種方案其實是不提倡的，這種方案存在的問題是快取更新成功，但是更新資料庫出現異常了。這樣會導致快取資料與資料庫資料完全不一致，而且很難察覺，因為快取中的資料一直都存在。

先更新資料庫，再更新快取

先更新資料庫，再更新快取，如果快取更新失敗了，其實也會導致資料庫和快取中的資料不一致，這樣客戶端請求過來的可能一直就是錯誤的資料。

更新資料庫之後更新快取

先刪除快取，後更新資料庫

這種場景在併發量比較小的時候可能問題不大，理想情況是應用訪問快取的時候，發現快取中的資料是空的，就會從資料庫中載入並且儲存到快取中，這樣資料是一致的，但是在高併發的極端情況下，由於刪除快取和更新資料庫非原子行為，所以這期間就會有其他的執行緒對其訪問。於是，如下圖。

高併發刪除快取，後更新資料庫

解釋一下上圖，老貓羅列了兩個執行緒，分別是執行緒1和執行緒2。

  1. 執行緒1會先刪除快取中的資料，但是尚未去更新資料庫。
  2. 此時執行緒2看到快取中的資料是空的，就會去資料庫中查詢該值，並且重新更新到快取中。
  3. 但是此時執行緒1並沒有更新成功，或者是事務還未提交（MySQL的事務隔離級別，會導致未提交的事務資料不會被另一個執行緒看到），由於執行緒2快於執行緒1，所以執行緒2去資料庫查詢得到舊值。
  4. 這種情況下最終發現快取中還是為舊值，但是資料庫中卻是最新的。

由此可見，這種方案其實也並不是完美的，在高併發的情況下還是會有問題。那麼下面的這種總歸是完美的了吧，有小夥伴肯定會這麼認為，讓我們一起來分析一下。

先更新資料庫，後刪除快取

先說結論，其實這種方案也並不是完美的。咱們透過下圖來說一個比較極端的場景。

更新資料庫，後刪除快取

上圖中，我們執行的時間順序是按照數字由小到大進行。在高併發場景下，我們說一下比較極端的場景。

上面有執行緒1和執行緒2兩個執行緒。其中執行緒1是讀執行緒，當然它也會負責將讀取的結果集同步到快取中，執行緒2是寫執行緒，主要負責更新和重新同步快取。

  1. 由於快取失效，所以執行緒1開始直接查詢的就是DB。
  2. 此時寫執行緒2開始了，由於它的速度較快，所以直接完成了DB的更新和快取的刪除更新。
  3. 當執行緒2完成之後，執行緒1又重新更新了快取，那此時快取中被更新之後的當然是舊值了。

如此，咱們又發現了問題，又出現了資料庫和快取不一致的情況。

那麼顯然上面的這四種方案其實都多多少少會存在問題，那麼究竟如何去保持資料庫和快取的一致性呢？

保證強一致性

如果有人問，那我們能否保證快取和DB的強一致性呢？回答當然是肯定的，那就是針對更新資料庫和重新整理快取這兩個動作加上鎖。當DB和快取資料完成同步之後再去釋放，一旦其中任何一個元件更新失敗，我們直接逆向回滾操作。我們可能還得做快照便於其歷史快取重寫。那這種設計顯然代價會很大。

其實在很大一部分情況下，要求快取和DB資料強一致大部分都是偽需求。我們可能只要達到最終儘量保持快取一致即可。有快取要求的大部分業務其實也是能接受資料在短期內不一致的情況。所以我們就可以使用下面的這兩種最終一致性的方案。

錯誤重試達到最終一致

如下示意圖所示：

基於訊息佇列

上面的圖中我們看到。當然上述老貓只是畫了更新執行緒，其實讀取執行緒也一樣。

  1. 更新執行緒優先更新資料，然後再去更新快取。
  2. 此時我們發現快取更新失敗了，咱們就將其重新放到訊息佇列中。
  3. 單獨寫一個消費者接收更新失敗記錄，然後進行重試更新操作。

說到訊息佇列重試，還有一種方式是基於非同步任務重試，咱們可以把更新快取失敗的這個資料儲存到資料庫，然後透過另外的一個定時任務進而掃描待執行任務，然後去做相關的快取更新動作。

當然上面我們提到的這兩種方案，其實比較依賴我們的業務程式碼做出相對應的調整。我們當然也可以藉助Canal元件來監控MySQL中的binlog的日誌。透過資料庫的 binlog 來非同步淘汰 key，利用工具(canal)將 binlog日誌採集傳送到 MQ 中，然後透過 ACK 機制確認處理刪除快取。先更新DB，然後再去更新快取，這種方式，被稱為 Cache Aside Pattern，屬於快取更新的經典設計模式之一。

基於canal

上述我們總結了快取使用的一些方案，我們發現其實沒有一種方案是完美的，最完美的方案其實還是得去結合具體的業務場景去使用。方案已經同步了，那麼如何去擼資料庫以及快取同步的程式碼呢？接下來，和大家分享的當然是日常開發中比較好用的SpringCache快取處理框架了。

SpringCache實戰

SpringCache是一個框架，實現了基於註解快取功能，只需要簡單地加一個註解，就能實現快取功能。
SpringCache提高了一層抽象，底層可以切換不同的cache實現，具體就是透過cacheManager介面來統一不同的快取技術,cacheManager是spring提供的各種快取技術抽象介面。

目前存在以下幾種：

  • EhCacheCacheManager：將快取的資料儲存在記憶體中,以提高應用程式的效能。
  • GuavaCaceManager：使用Google的GuavaCache作為快取技術。
  • RedisCacheManager：使用Redis作為快取技術。

配置

我們日常開發中用到比較多的其實是redis作為快取，所以咱們就可以用RedisCacheManager，做一下程式碼演示。咱們以springboot專案為例。

老貓這裡拿看一下redisCacheManager來舉例，專案開始的時候我們當忽然要在pom檔案依賴的時候就肯定需要redis啟用項。如下：

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<!--使用註解完成快取技術-->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-cache</artifactId>
</dependency>

因為我們在application.yml中就需要配置redis相關的配置項：

spring:
  redis:
    host: localhost
    port: 6379
    database: 0 
    jedis:
      pool:
        max-active: 8 # 最大連結資料
        max-wait: 1ms # 連線池最大阻塞等待時間
        max-idle: 4 # 連線線中最大的空閒連結
        min-idle: 0 # 連線池中最小空閒連結
   cache:
    redis:
      time-to-live: 1800000

常用註解

關於SpringCache常用的註解，整理如下:

SpringCache常用註解

針對上述的註解，咱們做一下demo用法，如下：

用法簡單盤點

@Slf4j
@SpringBootApplication
@ServletComponentScan
@EnableCaching
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(ReggieApplication.class);
    }
}

在service層我們注入所需要用到的cacheManager:

@Autowired
private CacheManager cacheManager;

/**
 * 公眾號：程式設計師老貓
 * 我們可以透過程式碼的方式主動清除快取，例如
 **/
public void clearCache(String productCode) {
  try {
      RedisCacheManager redisCacheManager = (RedisCacheManager) cacheManager;

      Cache backProductCache = redisCacheManager.getCache("backProduct");
      if(backProductCache != null) {
          backProductCache.evict(productCode);
      }
  } catch (Exception e) {
      logger.error("redis 快取清除失敗", e);
  }
}

接下來我們看一下每一個註解的用法,以下關於快取用法的註解，我們都可以將其加到dao層：

第一種@Cacheable：

在方法執行前spring先檢視快取中是否有資料，如果有資料，則直接返回快取資料；若沒有資料，呼叫方法並將方法返回值放到快取中。

@Cacheable 註解中的核心引數有以下幾個：

  • value：快取的名稱，可以是一個字串陣列，表示該方法的結果可以被快取到哪些快取中。預設值為一個空陣列，表示快取到預設的快取中。
  • key：快取的 key，可以是一個 SpEL 表示式，表示快取的 key 可以根據方法引數動態生成。預設值為一個空字串，表示使用預設的 key 生成策略。
  • condition：快取的條件，可以是一個 SpEL 表示式，表示快取的結果是否應該被快取。預設值為一個空字串，表示不考慮任何條件，快取所有結果。
  • unless：快取的排除條件，可以是一個 SpEL 表示式，表示快取的結果是否應該被排除在快取之外。預設值為一個空字串，表示不排除任何結果。

上述提及的SpEL是是Spring Framework中的一種表示式語言，此處不展開，不瞭解的小夥伴可以自己去查閱一下相關資料。

程式碼使用案例：

@Cacheable(value="picUrlPrefixDO",key="#id")
public PicUrlPrefixDO selectById(Long id) {
    PicUrlPrefixDO picUrlPrefixDO = writeSqlSessionTemplate.selectOne("PicUrlPrefixDao.selectById", id);
    return picUrlPrefixDO;
}

第二種@CachePut：

表示將方法返回的值放入快取中。
註解的引數列表和@Cacheable的引數列表一致，代表的意思也一樣。
程式碼使用案例：

@CachePut(value = "userCache",key = "#users.id")
@GetMapping()
public User get(User user){
   User users= dishService.getById(user);
   return users;
}

第三種@CacheEvict：

表示從快取中刪除資料。使用案例如下：

@CacheEvict(value="picUrlPrefixDO",key="#urfPrefix")
public Integer deleteByUrlPrefix(String urfPrefix) {
  return writeSqlSessionTemplate.delete("PicUrlPrefixDao.deleteByUrlPrefix", urfPrefix);
}

上述和大家分享了一下SpringCache的用法，對於上述提及的三個快取註解中，老貓在日常開發過程中用的比較多的是@CacheEvict以及@Cacheable，如果對SpringCache實現原理感興趣的小夥伴可以查閱一下相關的原始碼。

使用快取的其他注意點

當我們使用快取的時候，除了會遇到資料庫和快取不一致的情況之外，其實還有其他問題。嚴重的情況下可能還會出現快取雪崩。關於快取失效造成雪崩，大家可以看一下這裡【糟糕！快取擊穿，商詳頁進不去了】。

另外如果加了快取之後，應用程式啟動或服務高峰期之前，大家一定要做好快取預熱從而避免上線後瞬時大流量造成系統不可用。關於快取預熱的解決方案，由於篇幅過長老貓在此不展開了。不過方案概要可以提供，具體如下：

  • 定時預熱。採用定時任務將需要使用的資料預熱到快取中，以保證資料的熱度。
  • 啟動時載入預熱。在應用程式啟動時，將常用的資料提前載入到快取中，例如實現InitializingBean 介面，並在 afterPropertiesSet 方法中執行快取預熱的邏輯。
  • 手動觸發載入：在系統達到高峰期之前，手動觸發載入常用資料到快取中，以提高快取命中率和系統效能。
  • 熱點預熱。將系統中的熱點資料提前載入到快取中，以減輕系統壓力。5
  • 延遲非同步預熱。將需要預熱的資料放入一個佇列中，由後臺非同步任務來完成預熱。
  • 增量預熱。按需預熱資料，而不是一次性預熱所有資料。透過根據資料的訪問模式和優先順序逐步預熱資料，以減少預熱過程對系統的衝擊。

如果小夥伴們還有其他的預熱方式也歡迎大家留言。

總結

上述總結了關於快取在日常使用的時候的一些方案以及坑點，當然這些也是面試官最喜歡提問的一些點。文中關於快取的介紹老貓其實並沒有說完，很多其實還是需要小夥伴們自己去抽時間研究研究。不得不說快取是一門以空間換時間的藝術。要想使用好快取，死記硬背策略肯定是行不通的。真實的業務場景往往要複雜的多，當然解決方案也不同，老貓上面提及的這些大家可以做一個參考，遇到實際問題還是需要大傢俱體問題具體分析。

相關文章