緩存把我坑慘了...
故事
春天，辦公室外的世界總是讓人神往的，小貓戴著耳機，托著腮幫，望著外面美好的春光神游著...
一聲不和諧的座機電話聲打破這份本該屬于小貓的寧靜，“hi，小貓，線上有個客戶想購買A產品規格的商品，投訴說下單總是失敗，幫忙看一下啥原因。”客服部小姐姐甜美的聲音從電話那頭傳來。“哦哦，好，我看一下，把商品編號發一下吧......”
由于前一段時間的系統熟悉，小貓對現在的數據表模型已經了然于胸，當下就直接定位到了商品規格信息表，發現數據庫中客戶想購買的規格已經被下架了，但是前端的緩存好像并沒有被刷新。
小貓在系統中找到了之前開發人員留的后門接口，直接curl語句重新刷新了一下接口，緩存問題搞定了。
關于商品緩存和數據庫不一致的情況，其實小貓一周會遇到好幾個這樣的客訴，他深受DB以及緩存不一致的苦，于是他下定決心想要從根本上解決問題，而不是curl調用后門接口......
寫在前面
小貓的態度其實還是相當值得肯定的，當他下定決心從根本上排查問題的時候開始，小貓其實就是一名合格而且負責的研發，這也是我們每一位軟件研發人員所需要具備的處理事情的態度。
在軟件系統演進的過程中，只有我們在修復歷史遺留的問題的時候，才是真正意義上的對系統進行了維護，如果我們使用一些極端的手段(例如上述提到的后門接口curl語句)來保持古老而陳腐的代碼繼續工作的時候，這其實是一種茍且。一旦系統有了問題，我們其實就需要及時進行優化修復，否則會形成不好的示范，更多的后來者傾向于類似的方式解決問題，這也是為什么FixController存在的原因，這其實就是系統腐化的標志。
言歸正傳，關于緩存和DB不一致相信大家在日常開發的過程中都有遇到過，那么我們接下來就和大家好好盤一盤，緩存和DB不一致的時候，咱們是如何去解決的。接下來，大家會看到解決方案以及實戰。
圖片
常規接口緩存讀取更新
常規緩存讀取
看到上面的圖，我們可以清晰地知道緩存在實際場景中的工作原理。
- 發生請求的時候，優先讀取緩存，如果命中緩存則返回結果集。
- 如果緩存沒有命中，則回歸數據庫查詢。
- 將數據庫查詢得到的結果集再次同步到緩存中，并且返回對應的結果集。
這是大家比較熟悉的緩存使用方式，可以有效減輕數據庫壓力，提升接口訪問性能。但是在這樣的一個架構中，會有一個問題，就是一份數據同時保存在數據庫和緩存中，如果數據發生變化，需要同時更新緩存和數據庫，由于更新是有先后順序的，并且它不像數據庫中多表事務操作滿足ACID特性，所以這樣就會出現數據一致性的問題。
DB和緩存不一致方案與實戰DEMO
關于緩存和DB不一致，其實無非就是以下四種解決方案：
- 先更新緩存，再更新數據庫
- 先更新數據庫，再更新緩存
- 先刪除緩存，后更新數據庫
- 先更新數據庫，后刪除緩存
先更新緩存，再更新數據庫(不建議)
更新緩存后更新數據庫
這種方案其實是不提倡的，這種方案存在的問題是緩存更新成功，但是更新數據庫出現異常了。這樣會導致緩存數據與數據庫數據完全不一致，而且很難察覺，因為緩存中的數據一直都存在。
先更新數據庫，再更新緩存
先更新數據庫，再更新緩存，如果緩存更新失敗了，其實也會導致數據庫和緩存中的數據不一致，這樣客戶端請求過來的可能一直就是錯誤的數據。
更新數據庫之后更新緩存
先刪除緩存，后更新數據庫
這種場景在并發量比較小的時候可能問題不大，理想情況是應用訪問緩存的時候，發現緩存中的數據是空的，就會從數據庫中加載并且保存到緩存中，這樣數據是一致的，但是在高并發的極端情況下，由于刪除緩存和更新數據庫非原子行為，所以這期間就會有其他的線程對其訪問。于是，如下圖。
圖片
解釋一下上圖，老貓羅列了兩個線程，分別是線程1和線程2。
- 線程1會先刪除緩存中的數據，但是尚未去更新數據庫。
- 此時線程2看到緩存中的數據是空的，就會去數據庫中查詢該值，并且重新更新到緩存中。
- 但是此時線程1并沒有更新成功，或者是事務還未提交（MySQL的事務隔離級別，會導致未提交的事務數據不會被另一個線程看到），由于線程2快于線程1，所以線程2去數據庫查詢得到舊值。
- 這種情況下最終發現緩存中還是為舊值，但是數據庫中卻是最新的。
由此可見，這種方案其實也并不是完美的，在高并發的情況下還是會有問題。那么下面的這種總歸是完美的了吧，有小伙伴肯定會這么認為，讓我們一起來分析一下。
先更新數據庫，后刪除緩存
先說結論，其實這種方案也并不是完美的。咱們通過下圖來說一個比較極端的場景。
更新數據庫，后刪除緩存
上圖中，我們執行的時間順序是按照數字由小到大進行。在高并發場景下，我們說一下比較極端的場景。
上面有線程1和線程2兩個線程。其中線程1是讀線程，當然它也會負責將讀取的結果集同步到緩存中，線程2是寫線程，主要負責更新和重新同步緩存。
- 由于緩存失效，所以線程1開始直接查詢的就是DB。
- 此時寫線程2開始了，由于它的速度較快，所以直接完成了DB的更新和緩存的刪除更新。
- 當線程2完成之后，線程1又重新更新了緩存，那此時緩存中被更新之后的當然是舊值了。
如此，咱們又發現了問題，又出現了數據庫和緩存不一致的情況。
那么顯然上面的這四種方案其實都多多少少會存在問題，那么究竟如何去保持數據庫和緩存的一致性呢？
保證強一致性
如果有人問，那我們能否保證緩存和DB的強一致性呢？回答當然是肯定的，那就是針對更新數據庫和刷新緩存這兩個動作加上鎖。當DB和緩存數據完成同步之后再去釋放，一旦其中任何一個組件更新失敗，我們直接逆向回滾操作。我們可能還得做快照便于其歷史緩存重寫。那這種設計顯然代價會很大。
其實在很大一部分情況下，要求緩存和DB數據強一致大部分都是偽需求。我們可能只要達到最終盡量保持緩存一致即可。有緩存要求的大部分業務其實也是能接受數據在短期內不一致的情況。所以我們就可以使用下面的這兩種最終一致性的方案。
錯誤重試達到最終一致
如下示意圖所示：
基于消息隊列
上面的圖中我們看到。當然上述老貓只是畫了更新線程，其實讀取線程也一樣。
- 更新線程優先更新數據，然后再去更新緩存。
- 此時我們發現緩存更新失敗了，咱們就將其重新放到消息隊列中。
- 單獨寫一個消費者接收更新失敗記錄，然后進行重試更新操作。
說到消息隊列重試，還有一種方式是基于異步任務重試，咱們可以把更新緩存失敗的這個數據保存到數據庫，然后通過另外的一個定時任務進而掃描待執行任務，然后去做相關的緩存更新動作。
當然上面我們提到的這兩種方案，其實比較依賴我們的業務代碼做出相對應的調整。我們當然也可以借助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
- 延遲異步預熱。將需要預熱的數據放入一個隊列中，由后臺異步任務來完成預熱。
- 增量預熱。按需預熱數據，而不是一次性預熱所有數據。通過根據數據的訪問模式和優先級逐步預熱數據，以減少預熱過程對系統的沖擊。
總結
上述總結了關于緩存在日常使用的時候的一些方案以及坑點，當然這些也是面試官最喜歡提問的一些點。文中關于緩存的介紹老貓其實并沒有說完，很多其實還是需要小伙伴們自己去抽時間研究研究。不得不說緩存是一門以空間換時間的藝術。要想使用好緩存，死記硬背策略肯定是行不通的。真實的業務場景往往要復雜的多，當然解決方案也不同，老貓上面提及的這些大家可以做一個參考，遇到實際問題還是需要大家具體問題具體分析。
