在云服務(wù)中，緩存是極其重要的一點(diǎn)。所謂緩存，其實(shí)是一個(gè)高速數(shù)據(jù)存儲(chǔ)層。當(dāng)緩存存在后，日后再次請(qǐng)求該數(shù)據(jù)就會(huì)直接訪問緩存，提升數(shù)據(jù)訪問的速度。

但是緩存存儲(chǔ)的數(shù)據(jù)通常是短暫性的，這就需要經(jīng)常對(duì)緩存進(jìn)行更新。而我們操作緩存和數(shù)據(jù)庫，分為讀操作和寫操作。

讀操作的詳細(xì)流程為，請(qǐng)求數(shù)據(jù)，如緩存中存在數(shù)據(jù)則直接讀取并返回，如不存在則從數(shù)據(jù)庫中讀取，成功之后將數(shù)據(jù)放到緩存中。 寫操作則又分為以下 4 種：

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

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

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

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

一些一致性要求不高的數(shù)據(jù)，如點(diǎn)贊數(shù)等，可以先更新緩存，然后再定時(shí)同步到數(shù)據(jù)庫。而在其它情況下，我們通常會(huì)等數(shù)據(jù)庫操作成功，再操作緩存。

下面主要介紹更新數(shù)據(jù)庫成功后，更新緩存和刪除緩存這兩個(gè)操作的區(qū)別和改進(jìn)方案。

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

先更新數(shù)據(jù)庫，再刪除緩存，這種模式也叫 cache aside，是目前比較流行的處理緩存數(shù)據(jù)庫一致性的方法。它的優(yōu)點(diǎn)是：

出現(xiàn)數(shù)據(jù)不一致的概率極低，實(shí)現(xiàn)簡單

由于不更新緩存，而是刪除緩存，在并發(fā)寫寫情況下，不會(huì)出現(xiàn)數(shù)據(jù)不一致的情況

出現(xiàn)數(shù)據(jù)不一致的情況出現(xiàn)在并發(fā)讀寫的場景下，詳情可見下圖：



這種情況發(fā)生的概率比較低，必須要在某?時(shí)間區(qū)間同時(shí)存在兩個(gè)或多個(gè)寫?和多個(gè)讀取，所以大部分業(yè)務(wù)都容忍了這種小概率的不一致。

雖然發(fā)生的概率較低，但還是有一些方案可以讓影響降到更低。

優(yōu)化方案

第一種方案為：采用較短的過期時(shí)間來減少影響。這種方法有兩個(gè)缺點(diǎn)：

刪除后，讀請(qǐng)求會(huì) miss

如果緩存不一致，不一致的時(shí)間取決于過期時(shí)間設(shè)置

第二種方案則是采用延遲雙刪的策略，比如：1分鐘以后刪除緩存。這種做法也存在兩個(gè)缺點(diǎn)：

刪除緩存之前的時(shí)間里可能會(huì)有不一致

刪除后，讀請(qǐng)求會(huì) miss

第三種方案為雙更新策略，思路與延遲雙刪策略差不多。不同的點(diǎn)是，此方案不刪除緩存而是更新緩存，所以讀請(qǐng)求就不會(huì)發(fā)生 miss。但是另一個(gè)缺點(diǎn)還是存在。

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

相比先更新數(shù)據(jù)庫再刪除緩存的操作，先更新數(shù)據(jù)庫再更新緩存的操作可以避免用戶請(qǐng)求直接打到數(shù)據(jù)庫，進(jìn)而導(dǎo)致緩存穿透的問題。

此方案是更新緩存，我們需要關(guān)注并發(fā)讀寫和并發(fā)寫寫兩個(gè)場景下導(dǎo)致的數(shù)據(jù)不一致。 先來看看并發(fā)讀寫的情況，步驟如下圖所示：



可以看到由于 4 和 5 操作步驟都設(shè)置了緩存，如果步驟4發(fā)生在步驟5之前，那么會(huì)出現(xiàn)舊值覆蓋新值的情況，也就是緩存不一致的情況。這種情況只需要修改一下步驟5，便可解決。

優(yōu)化方案

可以通過在第五步不要 set cache，改用 add cache，redis 中使用 setnx 命令來進(jìn)行優(yōu)化。修改后步驟示意圖如下：



解決完了并發(fā)讀寫場景導(dǎo)致的數(shù)據(jù)不一致，再來看看并發(fā)寫寫情況導(dǎo)致的數(shù)據(jù)不一致問題。

出現(xiàn)不一致的情況如下圖所示，Thread A 比 Thread B 先更新完 DB，但是 Thread B 卻先更新完緩存，這就導(dǎo)致緩存會(huì)被 Thread A 的舊值所覆蓋。



這種情況也是有方法可以優(yōu)化的，下面介紹兩個(gè)主流方法：

使用分布式鎖

使用版本號(hào)

使用分布式鎖

要解決并發(fā)讀寫的問題，第一個(gè)思路就是消滅并發(fā)寫。而使用分布式鎖，讓寫操作排隊(duì)執(zhí)行，理論上就可以解決并發(fā)寫的問題，但現(xiàn)在并沒有可靠的分布式鎖實(shí)現(xiàn)方案。



不管是基于 Zookeeper，etcd 還是 redis 實(shí)現(xiàn)分布式鎖，為了防止程序掛掉而鎖不能釋放，我們都會(huì)給鎖設(shè)置租約/過期時(shí)間，想象一種場景：如果進(jìn)程卡頓幾分鐘（雖然概率較低），導(dǎo)致鎖失效，而其它線程獲取到鎖，此時(shí)就又出現(xiàn)了并發(fā)讀寫的場景了，還是有可能會(huì)造成數(shù)據(jù)不一致。

使用版本號(hào)

并發(fā)寫導(dǎo)致的數(shù)據(jù)不一致，是因?yàn)榈桶姹靖采w了高版本。那么我們可以想辦法不讓這種情況發(fā)生，一種可行的方案是引入版本號(hào)，如果寫入的數(shù)據(jù)低于現(xiàn)版本號(hào)，則放棄覆蓋。 缺點(diǎn)：

應(yīng)用層維護(hù)版本的代價(jià)很大，大規(guī)模落地很難

需修改數(shù)據(jù)模型，添加版本

每次需要修改，讓版本自增

不管是更新緩存還是刪除緩存，優(yōu)化以后都將出現(xiàn)數(shù)據(jù)不一致的概率降到最低了。但是有沒有一種辦法既簡單，又不會(huì)出現(xiàn)數(shù)據(jù)不一致的場景呢。下面就介紹一下 Rockscache。

Rockscache

簡介

Rockscache 也是一種保持緩存一致性的方法，它采用的緩存管理策略是：更新數(shù)據(jù)庫后，將緩存標(biāo)記為刪除。主要通過以下兩個(gè)方法來實(shí)現(xiàn)：

Fetch 函數(shù)實(shí)現(xiàn)了前面的查詢緩存

TagAsDeleted 函數(shù)實(shí)現(xiàn)了標(biāo)記刪除的邏輯

在運(yùn)行時(shí)只要讀數(shù)據(jù)時(shí)調(diào)用 Fetch，并且確保更新數(shù)據(jù)庫之后調(diào)用 TagAsDeleted，就能夠確保緩存最終一致。這一策略有 4 個(gè)特點(diǎn)：

不需要引入版本，幾乎可以適用于所有緩存場景

架構(gòu)上與"更新 DB 后刪除緩存”一樣，無額外負(fù)擔(dān)

性能高：變化只是將原來的 GET/SET/DELETE，替換為 Lua 腳本

強(qiáng)一致方案的性能也很高，與普通的防緩存擊穿方案一樣

在 Rockscache 策略中，緩存中的數(shù)據(jù)是包含幾個(gè)字段的 hash：

value：數(shù)據(jù)本身

lockUtil：數(shù)據(jù)鎖定到期時(shí)間，當(dāng)某個(gè)進(jìn)程查詢緩存無數(shù)據(jù)，那么先鎖定緩存一小段時(shí)間，然后查詢 DB，然后更新緩存

owner：數(shù)據(jù)鎖定者 uuid

證明

因?yàn)?Rockscache 方案并不更新緩存，所以只要確保并發(fā)讀寫數(shù)據(jù)一致性即可。

下面來看看 Rockscache 是怎么解決數(shù)據(jù)不一致的問題，先回憶一遍 cache aside 模式導(dǎo)致的數(shù)據(jù)不一致的原因 結(jié)合 cache aside 模式出現(xiàn)數(shù)據(jù)不一致的場景，來講講 Rockscache 是怎么解決的。



我們要解決的核心問題是，防止舊值寫入到緩存中。Rockscache 的解決方案是這樣的：

查詢請(qǐng)求，如果緩存中讀不到數(shù)據(jù)，還要做一個(gè)操作：鎖定緩存，為key設(shè)置一個(gè)uuid

寫請(qǐng)求在刪除緩存的時(shí)候，需要把鎖刪了

讀請(qǐng)求在設(shè)置緩存的時(shí)候，通過uuid比對(duì)，發(fā)現(xiàn)上鎖的不是自己，說明有寫請(qǐng)求把數(shù)據(jù)更新了，則放棄修改緩存

至此我們已經(jīng)完成了 rockscache 策略下的緩存更新。不過和其他緩存更新策略一樣，我們都默認(rèn)操作數(shù)據(jù)庫成功后，操作緩存肯定成功。

但是這是不對(duì)的，在實(shí)際操作過程即便操作數(shù)據(jù)庫成功，也可能出現(xiàn)緩存操作失敗的情況，因此可以通過以下 3 種方式來保證緩存更新成功：

本地消息表

監(jiān)聽 binlog

dtm 的二階段消息

除了緩存更新，Rockscache 還有以下兩種功能：

防止緩存擊穿

防止防止穿透和緩存雪崩

這都是非常實(shí)用的功能，推薦大家實(shí)際使用操作試試看。

審核編輯：劉清