故事

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

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

由于前一段時間的系統(tǒng)熟悉，小貓對現(xiàn)在的數(shù)據(jù)表模型已經(jīng)了然于胸，當下就直接定位到了商品規(guī)格信息表，發(fā)現(xiàn)數(shù)據(jù)庫中客戶想購買的規(guī)格已經(jīng)被下架了，但是前端的緩存好像并沒有被刷新。

小貓在系統(tǒng)中找到了之前開發(fā)人員留的后門接口，直接curl語句重新刷新了一下接口，緩存問題搞定了。

關(guān)于商品緩存和數(shù)據(jù)庫不一致的情況，其實小貓一周會遇到好幾個這樣的客訴，他深受DB以及緩存不一致的苦，于是他下定決心想要從根本上解決問題，而不是curl調(diào)用后門接口......

寫在前面

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

在軟件系統(tǒng)演進的過程中，只有我們在修復歷史遺留的問題的時候，才是真正意義上的對系統(tǒng)進行了維護，如果我們使用一些極端的手段(例如上述提到的后門接口curl語句)來保持古老而陳腐的代碼繼續(xù)工作的時候，這其實是一種茍且。一旦系統(tǒng)有了問題，我們其實就需要及時進行優(yōu)化修復，否則會形成不好的示范，更多的后來者傾向于類似的方式解決問題，這也是為什么FixController存在的原因，這其實就是系統(tǒng)腐化的標志。

言歸正傳，關(guān)于緩存和DB不一致相信大家在日常開發(fā)的過程中都有遇到過，那么我們接下來就和大家好好盤一盤，緩存和DB不一致的時候，咱們是如何去解決的。接下來，大家會看到解決方案以及實戰(zhàn)。

圖片

常規(guī)接口緩存讀取更新

常規(guī)緩存讀取

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

1. 發(fā)生請求的時候，優(yōu)先讀取緩存，如果命中緩存則返回結(jié)果集。
2. 如果緩存沒有命中，則回歸數(shù)據(jù)庫查詢。
3. 將數(shù)據(jù)庫查詢得到的結(jié)果集再次同步到緩存中，并且返回對應的結(jié)果集。

這是大家比較熟悉的緩存使用方式，可以有效減輕數(shù)據(jù)庫壓力，提升接口訪問性能。但是在這樣的一個架構(gòu)中，會有一個問題，就是一份數(shù)據(jù)同時保存在數(shù)據(jù)庫和緩存中，如果數(shù)據(jù)發(fā)生變化，需要同時更新緩存和數(shù)據(jù)庫，由于更新是有先后順序的，并且它不像數(shù)據(jù)庫中多表事務操作滿足ACID特性，所以這樣就會出現(xiàn)數(shù)據(jù)一致性的問題。

DB和緩存不一致方案與實戰(zhàn)DEMO

關(guān)于緩存和DB不一致，其實無非就是以下四種解決方案：

1. 先更新緩存，再更新數(shù)據(jù)庫
2. 先更新數(shù)據(jù)庫，再更新緩存
3. 先刪除緩存，后更新數(shù)據(jù)庫
4. 先更新數(shù)據(jù)庫，后刪除緩存

先更新緩存，再更新數(shù)據(jù)庫(不建議)

更新緩存后更新數(shù)據(jù)庫

這種方案其實是不提倡的，這種方案存在的問題是緩存更新成功，但是更新數(shù)據(jù)庫出現(xiàn)異常了。這樣會導致緩存數(shù)據(jù)與數(shù)據(jù)庫數(shù)據(jù)完全不一致，而且很難察覺，因為緩存中的數(shù)據(jù)一直都存在。

先更新數(shù)據(jù)庫，再更新緩存

先更新數(shù)據(jù)庫，再更新緩存，如果緩存更新失敗了，其實也會導致數(shù)據(jù)庫和緩存中的數(shù)據(jù)不一致，這樣客戶端請求過來的可能一直就是錯誤的數(shù)據(jù)。

更新數(shù)據(jù)庫之后更新緩存

先刪除緩存，后更新數(shù)據(jù)庫

這種場景在并發(fā)量比較小的時候可能問題不大，理想情況是應用訪問緩存的時候，發(fā)現(xiàn)緩存中的數(shù)據(jù)是空的，就會從數(shù)據(jù)庫中加載并且保存到緩存中，這樣數(shù)據(jù)是一致的，但是在高并發(fā)的極端情況下，由于刪除緩存和更新數(shù)據(jù)庫非原子行為，所以這期間就會有其他的線程對其訪問。于是，如下圖。

圖片

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

1. 線程1會先刪除緩存中的數(shù)據(jù)，但是尚未去更新數(shù)據(jù)庫。
2. 此時線程2看到緩存中的數(shù)據(jù)是空的，就會去數(shù)據(jù)庫中查詢該值，并且重新更新到緩存中。
3. 但是此時線程1并沒有更新成功，或者是事務還未提交（MySQL的事務隔離級別，會導致未提交的事務數(shù)據(jù)不會被另一個線程看到），由于線程2快于線程1，所以線程2去數(shù)據(jù)庫查詢得到舊值。
4. 這種情況下最終發(fā)現(xiàn)緩存中還是為舊值，但是數(shù)據(jù)庫中卻是最新的。

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

先更新數(shù)據(jù)庫，后刪除緩存

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

更新數(shù)據(jù)庫，后刪除緩存

上圖中，我們執(zhí)行的時間順序是按照數(shù)字由小到大進行。在高并發(fā)場景下，我們說一下比較極端的場景。

上面有線程1和線程2兩個線程。其中線程1是讀線程，當然它也會負責將讀取的結(jié)果集同步到緩存中，線程2是寫線程，主要負責更新和重新同步緩存。

1. 由于緩存失效，所以線程1開始直接查詢的就是DB。
2. 此時寫線程2開始了，由于它的速度較快，所以直接完成了DB的更新和緩存的刪除更新。
3. 當線程2完成之后，線程1又重新更新了緩存，那此時緩存中被更新之后的當然是舊值了。

如此，咱們又發(fā)現(xiàn)了問題，又出現(xiàn)了數(shù)據(jù)庫和緩存不一致的情況。

那么顯然上面的這四種方案其實都多多少少會存在問題，那么究竟如何去保持數(shù)據(jù)庫和緩存的一致性呢？

保證強一致性

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

其實在很大一部分情況下，要求緩存和DB數(shù)據(jù)強一致大部分都是偽需求。我們可能只要達到最終盡量保持緩存一致即可。有緩存要求的大部分業(yè)務其實也是能接受數(shù)據(jù)在短期內(nèi)不一致的情況。所以我們就可以使用下面的這兩種最終一致性的方案。

錯誤重試達到最終一致

如下示意圖所示：

基于消息隊列

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

1. 更新線程優(yōu)先更新數(shù)據(jù)，然后再去更新緩存。
2. 此時我們發(fā)現(xiàn)緩存更新失敗了，咱們就將其重新放到消息隊列中。
3. 單獨寫一個消費者接收更新失敗記錄，然后進行重試更新操作。

說到消息隊列重試，還有一種方式是基于異步任務重試，咱們可以把更新緩存失敗的這個數(shù)據(jù)保存到數(shù)據(jù)庫，然后通過另外的一個定時任務進而掃描待執(zhí)行任務，然后去做相關(guān)的緩存更新動作。

當然上面我們提到的這兩種方案，其實比較依賴我們的業(yè)務代碼做出相對應的調(diào)整。我們當然也可以借助Canal組件來監(jiān)控MySQL中的binlog的日志。通過數(shù)據(jù)庫的 binlog 來異步淘汰 key，利用工具(canal)將 binlog日志采集發(fā)送到 MQ 中，然后通過 ACK 機制確認處理刪除緩存。先更新DB，然后再去更新緩存，這種方式，被稱為 Cache Aside Pattern，屬于緩存更新的經(jīng)典設計模式之一。

基于canal

上述我們總結(jié)了緩存使用的一些方案，我們發(fā)現(xiàn)其實沒有一種方案是完美的，最完美的方案其實還是得去結(jié)合具體的業(yè)務場景去使用。方案已經(jīng)同步了，那么如何去擼數(shù)據(jù)庫以及緩存同步的代碼呢？接下來，和大家分享的當然是日常開發(fā)中比較好用的SpringCache緩存處理框架了。

SpringCache實戰(zhàn)

SpringCache是一個框架，實現(xiàn)了基于注解緩存功能，只需要簡單地加一個注解，就能實現(xiàn)緩存功能。SpringCache提高了一層抽象，底層可以切換不同的cache實現(xiàn)，具體就是通過cacheManager接口來統(tǒng)一不同的緩存技術(shù),cacheManager是spring提供的各種緩存技術(shù)抽象接口。

目前存在以下幾種：

• EhCacheCacheManager：將緩存的數(shù)據(jù)存儲在內(nèi)存中,以提高應用程序的性能。
• GuavaCaceManager：使用Google的GuavaCache作為緩存技術(shù)。
• RedisCacheManager：使用Redis作為緩存技術(shù)。

配置

我們?nèi)粘ｉ_發(fā)中用到比較多的其實是redis作為緩存，所以咱們就可以用RedisCacheManager，做一下代碼演示。咱們以springboot項目為例。

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

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<!--使用注解完成緩存技術(shù)-->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-cache</artifactId>
</dependency>

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

spring:
  redis:
    host: localhost
    port: 6379
    database: 0 
    jedis:
      pool:
        max-active: 8 # 最大鏈接數(shù)據(jù)
        max-wait: 1ms # 連接池最大阻塞等待時間
        max-idle: 4 # 連接線中最大的空閑鏈接
        min-idle: 0 # 連接池中最小空閑鏈接
   cache:
    redis:
      time-to-live: 1800000

常用注解

關(guān)于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);
  }
}

接下來我們看一下每一個注解的用法,以下關(guān)于緩存用法的注解，我們都可以將其加到dao層：

第一種@Cacheable：

在方法執(zhí)行前spring先查看緩存中是否有數(shù)據(jù)，如果有數(shù)據(jù)，則直接返回緩存數(shù)據(jù)；若沒有數(shù)據(jù)，調(diào)用方法并將方法返回值放到緩存中。

@Cacheable 注解中的核心參數(shù)有以下幾個：

• value：緩存的名稱，可以是一個字符串數(shù)組，表示該方法的結(jié)果可以被緩存到哪些緩存中。默認值為一個空數(shù)組，表示緩存到默認的緩存中。
• key：緩存的 key，可以是一個 SpEL 表達式，表示緩存的 key 可以根據(jù)方法參數(shù)動態(tài)生成。默認值為一個空字符串，表示使用默認的 key 生成策略。
• condition：緩存的條件，可以是一個 SpEL 表達式，表示緩存的結(jié)果是否應該被緩存。默認值為一個空字符串，表示不考慮任何條件，緩存所有結(jié)果。
• unless：緩存的排除條件，可以是一個 SpEL 表達式，表示緩存的結(jié)果是否應該被排除在緩存之外。默認值為一個空字符串，表示不排除任何結(jié)果。

上述提及的SpEL是Spring Framework中的一種表達式語言，此處不展開，不了解的小伙伴可以自己去查閱一下相關(guān)資料。

代碼使用案例：

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

第二種@CachePut：

表示將方法返回的值放入緩存中。注解的參數(shù)列表和@Cacheable的參數(shù)列表一致，代表的意思也一樣。代碼使用案例：

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

第三種@CacheEvict：

表示從緩存中刪除數(shù)據(jù)。使用案例如下：

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

上述和大家分享了一下SpringCache的用法，對于上述提及的三個緩存注解中，老貓在日常開發(fā)過程中用的比較多的是@CacheEvict以及@Cacheable，如果對SpringCache實現(xiàn)原理感興趣的小伙伴可以查閱一下相關(guān)的源碼。

使用緩存的其他注意點

當我們使用緩存的時候，除了會遇到數(shù)據(jù)庫和緩存不一致的情況之外，其實還有其他問題。嚴重的情況下可能還會出現(xiàn)緩存雪崩。關(guān)于緩存失效造成雪崩，大家可以看一下這里【糟糕！緩存擊穿，商詳頁進不去了】。

另外如果加了緩存之后，應用程序啟動或服務高峰期之前，大家一定要做好緩存預熱從而避免上線后瞬時大流量造成系統(tǒng)不可用。關(guān)于緩存預熱的解決方案，由于篇幅過長老貓在此不展開了。不過方案概要可以提供，具體如下：

• 定時預熱。采用定時任務將需要使用的數(shù)據(jù)預熱到緩存中，以保證數(shù)據(jù)的熱度。
• 啟動時加載預熱。在應用程序啟動時，將常用的數(shù)據(jù)提前加載到緩存中，例如實現(xiàn)InitializingBean 接口，并在 afterPropertiesSet 方法中執(zhí)行緩存預熱的邏輯。
• 手動觸發(fā)加載：在系統(tǒng)達到高峰期之前，手動觸發(fā)加載常用數(shù)據(jù)到緩存中，以提高緩存命中率和系統(tǒng)性能。
• 熱點預熱。將系統(tǒng)中的熱點數(shù)據(jù)提前加載到緩存中，以減輕系統(tǒng)壓力。5
• 延遲異步預熱。將需要預熱的數(shù)據(jù)放入一個隊列中，由后臺異步任務來完成預熱。
• 增量預熱。按需預熱數(shù)據(jù)，而不是一次性預熱所有數(shù)據(jù)。通過根據(jù)數(shù)據(jù)的訪問模式和優(yōu)先級逐步預熱數(shù)據(jù)，以減少預熱過程對系統(tǒng)的沖擊。

總結(jié)

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