故事

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

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

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

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

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

寫在前面

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

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

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

圖片

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

常規(guī)緩存讀取

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

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

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

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

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

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

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

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

這種方案其實(shí)是不提倡的，這種方案存在的問題是緩存更新成功，但是更新數(shù)據(jù)庫出現(xiàn)異常了。這樣會(huì)導(dǎo)致緩存數(shù)據(jù)與數(shù)據(jù)庫數(shù)據(jù)完全不一致，而且很難察覺，因?yàn)榫彺嬷械臄?shù)據(jù)一直都存在。

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

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

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

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

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

圖片

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

1. 線程1會(huì)先刪除緩存中的數(shù)據(jù)，但是尚未去更新數(shù)據(jù)庫。
2. 此時(shí)線程2看到緩存中的數(shù)據(jù)是空的，就會(huì)去數(shù)據(jù)庫中查詢?cè)撝担⑶抑匦赂碌骄彺嬷小?/li>
3. 但是此時(shí)線程1并沒有更新成功，或者是事務(wù)還未提交（MySQL的事務(wù)隔離級(jí)別，會(huì)導(dǎo)致未提交的事務(wù)數(shù)據(jù)不會(huì)被另一個(gè)線程看到），由于線程2快于線程1，所以線程2去數(shù)據(jù)庫查詢得到舊值。
4. 這種情況下最終發(fā)現(xiàn)緩存中還是為舊值，但是數(shù)據(jù)庫中卻是最新的。

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

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

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

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

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

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

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

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

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

保證強(qiáng)一致性

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

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

錯(cuò)誤重試達(dá)到最終一致

如下示意圖所示：

基于消息隊(duì)列

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

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

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

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

基于canal

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

SpringCache實(shí)戰(zhàn)

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

目前存在以下幾種：

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

配置

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

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

<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>

因?yàn)槲覀冊(cè)赼pplication.yml中就需要配置redis相關(guān)的配置項(xiàng)：

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

常用注解

關(guān)于SpringCache常用的注解，整理如下:

SpringCache常用注解

針對(duì)上述的注解，咱們做一下demo用法，如下：

用法簡單盤點(diǎn)

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

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

@Autowired
private CacheManager cacheManager;

/**
 * 公眾號(hào)：程序員老貓
 * 我們可以通過代碼的方式主動(dòng)清除緩存，例如
 **/
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);
  }
}

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

第一種@Cacheable：

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

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

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

上述提及的SpEL是Spring Framework中的一種表達(dá)式語言，此處不展開，不了解的小伙伴可以自己去查閱一下相關(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的用法，對(duì)于上述提及的三個(gè)緩存注解中，老貓?jiān)谌粘ｉ_發(fā)過程中用的比較多的是@CacheEvict以及@Cacheable，如果對(duì)SpringCache實(shí)現(xiàn)原理感興趣的小伙伴可以查閱一下相關(guān)的源碼。

使用緩存的其他注意點(diǎn)

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

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

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

總結(jié)

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