先闡明一下 Mysql 和 Redis 的關(guān)系：Mysql 是數(shù)據(jù)庫，用來持久化數(shù)據(jù)，一定程度上保證數(shù)據(jù)的可靠性；Redis 是用來當(dāng)緩存，用來提升數(shù)據(jù)訪問的性能。

關(guān)于如何保證 Mysql 和 Redis 中的數(shù)據(jù)一致（即緩存一致性問題），這是一個(gè)非常經(jīng)典的問題。

使用過緩存的人都應(yīng)該知道，在實(shí)際應(yīng)用場景中，要想實(shí)時(shí)刻保證緩存和數(shù)據(jù)庫中的數(shù)據(jù)一樣，很難做到。

基本上都是盡可能讓他們的數(shù)據(jù)在絕大部分時(shí)間內(nèi)保持一致，并保證最終是一致的。

緩存不一致是如何產(chǎn)生的

如果數(shù)據(jù)一直沒有變更，那么就不會(huì)出現(xiàn)緩存不一致的問題。

通常緩存不一致是發(fā)生在數(shù)據(jù)有變更的時(shí)候。 因?yàn)槊看螖?shù)據(jù)變更你需要同時(shí)操作數(shù)據(jù)庫和緩存，而他們又屬于不同的系統(tǒng)，無法做到同時(shí)操作成功或失敗，總會(huì)有一個(gè)時(shí)間差。在并發(fā)讀寫的時(shí)候可能就會(huì)出現(xiàn)緩存不一致的問題（理論上通過分布式事務(wù)可以保證這一點(diǎn)，不過實(shí)際上基本上很少有人這么做）。

雖然沒辦法在數(shù)據(jù)有變更時(shí)，保證緩存和數(shù)據(jù)庫強(qiáng)一致，但對緩存的更新還是有一定設(shè)計(jì)方法的，遵循這些設(shè)計(jì)方法，能夠讓這個(gè)不一致的影響時(shí)間和影響范圍最小化。

緩存更新的幾種設(shè)計(jì)

緩存更新的設(shè)計(jì)方法大概有以下四種：

先刪除緩存，再更新數(shù)據(jù)庫（這種方法在并發(fā)下最容易出現(xiàn)長時(shí)間的臟數(shù)據(jù)，不可取）

先更新數(shù)據(jù)庫，刪除緩存（Cache Aside Pattern）

只更新緩存，由緩存自己同步更新數(shù)據(jù)庫（Read/Write Through Pattern）

只更新緩存，由緩存自己異步更新數(shù)據(jù)庫（Write Behind Cache Pattern）

接下來詳細(xì)介紹一些這四種設(shè)計(jì)方法

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

這種方法在并發(fā)讀寫的情況下容易出現(xiàn)緩存不一致的問題

如上圖所示，其可能的執(zhí)行流程順序?yàn)椋?/p>

客戶端 1 觸發(fā)更新數(shù)據(jù) A 的邏輯

客戶端 2 觸發(fā)查詢數(shù)據(jù) A 的邏輯

客戶端 1 刪除緩存中數(shù)據(jù) A

客戶端 2 查詢緩存中數(shù)據(jù) A，未命中

客戶端 2 從數(shù)據(jù)庫查詢數(shù)據(jù) A，并更新到緩存中

客戶端 1 更新數(shù)據(jù)庫中數(shù)據(jù) A

可見，最后緩存中的數(shù)據(jù) A 跟數(shù)據(jù)庫中的數(shù)據(jù) A 是不一致的，緩存中的數(shù)據(jù) A 是舊的臟數(shù)據(jù)。

因此一般不建議使用這種方式。

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

這種方法在并發(fā)讀寫的情況下，也可能會(huì)出現(xiàn)短暫緩存不一致的問題

如上圖所示，其可能執(zhí)行的流程順序?yàn)椋?/p>

客戶端 1 觸發(fā)更新數(shù)據(jù) A 的邏輯

客戶端 2 觸發(fā)查詢數(shù)據(jù) A 的邏輯

客戶端 3 觸發(fā)查詢數(shù)據(jù) A 的邏輯

客戶端 1 更新數(shù)據(jù)庫中數(shù)據(jù) A

客戶端 2 查詢緩存中數(shù)據(jù) A，命中返回（舊數(shù)據(jù)）

客戶端 1 讓緩存中數(shù)據(jù) A 失效

客戶端 3 查詢緩存中數(shù)據(jù) A，未命中

客戶端 3 查詢數(shù)據(jù)庫中數(shù)據(jù) A，并更新到緩存中

可見，最后緩存中的數(shù)據(jù) A 和數(shù)據(jù)庫中的數(shù)據(jù) A 是一致的，理論上可能會(huì)出現(xiàn)一小段時(shí)間數(shù)據(jù)不一致，不過這種概率也比較低，大部分的業(yè)務(wù)也不會(huì)有太大的問題。

只更新緩存，由緩存自己同步更新數(shù)據(jù)庫（Read/Write Through Pattern）

這種方法相當(dāng)于是業(yè)務(wù)只更新緩存，再由緩存去同步更新數(shù)據(jù)庫。 一個(gè) Write Through 的 例子如下：

如上圖所示，其可能執(zhí)行的流程順序?yàn)椋?/p>

客戶端 1 觸發(fā)更新數(shù)據(jù) A 的邏輯

客戶端 2 觸發(fā)查詢數(shù)據(jù) A 的邏輯

客戶端 1 更新緩存中數(shù)據(jù) A，緩存同步更新數(shù)據(jù)庫中數(shù)據(jù) A，再返回結(jié)果

客戶端 2 查詢緩存中數(shù)據(jù) A，命中返回

Read Through 和 WriteThrough 的流程類似，只是在客戶端查詢數(shù)據(jù) A 時(shí)，如果緩存中數(shù)據(jù) A 失效了（過期或被驅(qū)逐淘汰），則緩存會(huì)同步去數(shù)據(jù)庫中查詢數(shù)據(jù) A，并緩存起來，再返回給客戶端

這種方式緩存不一致的概率極低，只不過需要對緩存進(jìn)行專門的改造。

只更新緩存，由緩存自己異步更新數(shù)據(jù)庫（Write Behind Cache Pattern）

這種方式性詳單于是業(yè)務(wù)只操作更新緩存，再由緩存異步去更新數(shù)據(jù)庫，例如：

如上圖所示，其可能的執(zhí)行流程順序?yàn)椋?/p>

客戶端 1 觸發(fā)更新數(shù)據(jù) A 的邏輯

客戶端 2 觸發(fā)查詢數(shù)據(jù) A 的邏輯

客戶端 1 更新緩存中的數(shù)據(jù) A，返回

客戶端 2 查詢緩存中的數(shù)據(jù) A，命中返回

緩存異步更新數(shù)據(jù) A 到數(shù)據(jù)庫中

這種方式的優(yōu)勢是讀寫的性能都非常好，基本上只要操作完內(nèi)存后就返回給客戶端了，但是其是非強(qiáng)一致性，存在丟失數(shù)據(jù)的情況。

如果在緩存異步將數(shù)據(jù)更新到數(shù)據(jù)庫中時(shí)，緩存服務(wù)掛了，此時(shí)未更新到數(shù)據(jù)庫中的數(shù)據(jù)就丟失了。

總結(jié)

上面講到的幾種緩存更新的設(shè)計(jì)方式，都是前人總結(jié)出來的經(jīng)驗(yàn)，這些方式或多或少都有一些弊端，并不完美，實(shí)際上也很難有完美的設(shè)計(jì)。 大家在做系統(tǒng)設(shè)計(jì)的時(shí)候，也不要去追求完美，要有一些取舍，找到一種最適合自己業(yè)務(wù)場景的方式就行

作者：追光者