當(dāng)執(zhí)行寫(xiě)操作后，需要保證從緩存讀取到的數(shù)據(jù)與數(shù)據(jù)庫(kù)中持久化的數(shù)據(jù)是一致的，因此需要對(duì)緩存進(jìn)行更新。

因?yàn)樯婕暗綌?shù)據(jù)庫(kù)和緩存兩步操作，難以保證更新的原子性。

在設(shè)計(jì)更新策略時(shí)，我們需要考慮多個(gè)方面的問(wèn)題:

對(duì)系統(tǒng)吞吐量的影響：比如更新緩存策略產(chǎn)生的數(shù)據(jù)庫(kù)負(fù)載小于刪除緩存策略的負(fù)載

并發(fā)安全性：并發(fā)讀寫(xiě)時(shí)某些異常操作順序可能造成數(shù)據(jù)不一致，如緩存中長(zhǎng)期保存過(guò)時(shí)數(shù)據(jù)

更新失敗的影響：若某個(gè)操作失敗，如何對(duì)業(yè)務(wù)影響降到最小

檢測(cè)和修復(fù)故障的難度: 操作失敗導(dǎo)致的錯(cuò)誤會(huì)在日志留下詳細(xì)的記錄容易檢測(cè)和修復(fù)。并發(fā)問(wèn)題導(dǎo)致的數(shù)據(jù)錯(cuò)誤沒(méi)有明顯的痕跡難以發(fā)現(xiàn)，且在流量高峰期更容易產(chǎn)生并發(fā)錯(cuò)誤產(chǎn)生的業(yè)務(wù)風(fēng)險(xiǎn)較大。

更新緩存有兩種方式:

刪除失效緩存: 讀取時(shí)會(huì)因?yàn)槲疵芯彺娑鴱臄?shù)據(jù)庫(kù)中讀取新的數(shù)據(jù)并更新到緩存中

更新緩存: 直接將新的數(shù)據(jù)寫(xiě)入緩存覆蓋過(guò)期數(shù)據(jù)

更新緩存和更新數(shù)據(jù)庫(kù)有兩種順序：

先數(shù)據(jù)庫(kù)后緩存

先緩存后數(shù)據(jù)庫(kù)

兩兩組合共有四種更新策略，現(xiàn)在我們逐一進(jìn)行分析。

并發(fā)問(wèn)題通常由于后開(kāi)始的線程卻先完成操作導(dǎo)致，我們把這種現(xiàn)象稱為“搶跑”。下面我們逐一分析四種策略中“搶跑”帶來(lái)的錯(cuò)誤。

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

若數(shù)據(jù)庫(kù)更新成功，刪除緩存操作失敗，則此后讀到的都是緩存中過(guò)期的數(shù)據(jù)，造成不一致問(wèn)題。

可能存在讀寫(xiě)線程競(jìng)爭(zhēng)導(dǎo)致的并發(fā)錯(cuò)誤:

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

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

同刪除緩存策略一樣，若數(shù)據(jù)庫(kù)更新成功緩存更新失敗則會(huì)造成數(shù)據(jù)不一致問(wèn)題。

該策略同樣存在讀寫(xiě)線程競(jìng)爭(zhēng)導(dǎo)致數(shù)據(jù)不一致的問(wèn)題:

也可能因?yàn)閮蓚€(gè)寫(xiě)線程競(jìng)爭(zhēng)導(dǎo)致并發(fā)錯(cuò)誤:

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

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

可能發(fā)生的并發(fā)錯(cuò)誤:

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

若緩存更新成功數(shù)據(jù)庫(kù)更新失敗， 則此后讀到的都是未持久化的數(shù)據(jù)。因?yàn)榫彺嬷械臄?shù)據(jù)是易失的，這種狀態(tài)非常危險(xiǎn)。

因?yàn)閿?shù)據(jù)庫(kù)因?yàn)殒I約束導(dǎo)致寫(xiě)入失敗的可能性較高，所以這種策略風(fēng)險(xiǎn)較大。

可能發(fā)生的并發(fā)錯(cuò)誤:

兩個(gè)寫(xiě)線程競(jìng)爭(zhēng)也會(huì)導(dǎo)致數(shù)據(jù)不一致:

解決方案

使用 CAS

CAS (Check-And-Set 或 Compare-And-Swap)是一種常見(jiàn)的保證并發(fā)安全的手段。CAS 當(dāng)且僅當(dāng)客戶端最后一次取值后該 key 沒(méi)有被其他客戶端修改的情況下，才允許當(dāng)前客戶端將新值寫(xiě)入。

funcCAS(oldVal,newVal){
ifcache.get()==oldVal{
cache.set(newVal)
}
}

由上圖可見(jiàn)，CAS 可以有效的避免并發(fā)錯(cuò)誤的發(fā)生。

目前一些兼容 Redis 協(xié)議的中間件已經(jīng)提供了 CAS 命令的支持，比如阿里的 Tair 以及騰訊的 Tendis。

Redis 官方提供了 Watch + 事務(wù)的方法來(lái)支持 CAS, 或者使用 redis 中 lua 腳本原子性執(zhí)行的特點(diǎn)來(lái)實(shí)現(xiàn) CAS。不過(guò)由于代碼較為復(fù)雜，這兩種方案都不常見(jiàn)。

使用分布式鎖

CAS 假設(shè)發(fā)生并發(fā)問(wèn)題的概率不大, 所以 CAS 也被稱為樂(lè)觀鎖。那么悲觀鎖能否解決我們的問(wèn)題呢？

還是以「先更新數(shù)據(jù)庫(kù)，再更新緩存」方案中兩個(gè)寫(xiě)線程競(jìng)爭(zhēng)為例， 我們要求任何線程在寫(xiě)入或讀取數(shù)據(jù)庫(kù)前都需要獲取排它鎖。

分布式鎖同樣可以解決并發(fā)問(wèn)題，只是成本可能略高。

異步更新

阿里開(kāi)源了 MySQL 數(shù)據(jù)庫(kù)binlog的增量訂閱和消費(fèi)組件 - canal。canal 模擬從庫(kù)獲得主庫(kù)的 binlog 更新，然后將更新數(shù)據(jù)寫(xiě)入 MQ 或直接進(jìn)行消費(fèi)。

我們可以讓API服務(wù)器只負(fù)責(zé)寫(xiě)入數(shù)據(jù)庫(kù)，另一個(gè)線程訂閱數(shù)據(jù)庫(kù) binlog 增量進(jìn)行緩存更新。

因?yàn)?binlog 是有序的，因此可以避免兩個(gè)寫(xiě)線程競(jìng)爭(zhēng)。但我們?nèi)匀恍枰鉀Q讀寫(xiě)線程競(jìng)爭(zhēng)的問(wèn)題:

這里同樣可以 CAS 解千愁：

延時(shí)雙刪

使用刪除緩存策略時(shí)讀線程先開(kāi)始卻后寫(xiě)緩存會(huì)導(dǎo)致不一致，那么我們?cè)谧x線程結(jié)束后再次清除緩存是不是就可以解除錯(cuò)誤狀態(tài)了？延時(shí)雙刪就是寫(xiě)線程等待一段時(shí)間“確?！弊x線程都結(jié)束后再次刪除緩存，以此清除可能的錯(cuò)誤緩存數(shù)據(jù)。

理論上我們無(wú)法給出一個(gè)時(shí)間來(lái)“確?！弊x線程都結(jié)束，所以仍有存在并發(fā)問(wèn)題的可能。但是延時(shí)雙刪實(shí)現(xiàn)成本很低而且極大的減少了并發(fā)問(wèn)題出現(xiàn)的概率，不失為一種簡(jiǎn)單實(shí)用的手段。

審核編輯：劉清