為什么寫這篇文章？

正文

先做一個(gè)說明，從理論上來說，給緩存設(shè)置過期時(shí)間，是保證最終一致性的解決方案。這種方案下，我們可以對存入緩存的數(shù)據(jù)設(shè)置過期時(shí)間，所有的寫操作以數(shù)據(jù)庫為準(zhǔn)，對緩存操作只是盡***努力即可。也就是說如果數(shù)據(jù)庫寫成功，緩存更新失敗，那么只要到達(dá)過期時(shí)間，則后面的讀請求自然會從數(shù)據(jù)庫中讀取新值然后回填緩存。因此，接下來討論的思路不依賴于給緩存設(shè)置過期時(shí)間這個(gè)方案。

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

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

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

   應(yīng)該沒人問我，為什么沒有先更新緩存，再更新數(shù)據(jù)庫這種策略。

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

這套方案，大家是普遍反對的。為什么呢？有如下兩點(diǎn)原因。

原因一（線程安全角度）

同時(shí)有請求A和請求B進(jìn)行更新操作，那么會出現(xiàn)

1. 線程A更新了數(shù)據(jù)庫

2. 線程B更新了數(shù)據(jù)庫

3. 線程B更新了緩存

4. 線程A更新了緩存

這就出現(xiàn)請求A更新緩存應(yīng)該比請求B更新緩存早才對，但是因?yàn)榫W(wǎng)絡(luò)等原因，B卻比A更早更新了緩存。這就導(dǎo)致了臟數(shù)據(jù)，因此不考慮。

原因二（業(yè)務(wù)場景角度）

有如下兩點(diǎn)：

1. 如果你是一個(gè)寫數(shù)據(jù)庫場景比較多，而讀數(shù)據(jù)場景比較少的業(yè)務(wù)需求，采用這種方案就會導(dǎo)致，數(shù)據(jù)壓根還沒讀到，緩存就被頻繁的更新，浪費(fèi)性能。
2. 如果你寫入數(shù)據(jù)庫的值，并不是直接寫入緩存的，而是要經(jīng)過一系列復(fù)雜的計(jì)算再寫入緩存。那么，每次寫入數(shù)據(jù)庫后，都再次計(jì)算寫入緩存的值，無疑是浪費(fèi)性能的。顯然，刪除緩存更為適合。

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

該方案會導(dǎo)致不一致的原因是。同時(shí)有一個(gè)請求A進(jìn)行更新操作，另一個(gè)請求B進(jìn)行查詢操作。那么會出現(xiàn)如下情形:

1. 請求A進(jìn)行寫操作，刪除緩存

2. 請求B查詢發(fā)現(xiàn)緩存不存在

3. 請求B去數(shù)據(jù)庫查詢得到舊值
4. 請求B將舊值寫入緩存
5. 請求A將新值寫入數(shù)據(jù)庫

轉(zhuǎn)化為中文描述就是

1. 先淘汰緩存
2. 再寫數(shù)據(jù)庫（這兩步和原來一樣）
3. 休眠1秒，再次淘汰緩存

這么做，可以將1秒內(nèi)所造成的緩存臟數(shù)據(jù)，再次刪除。

那么，這個(gè)1秒怎么確定的，具體該休眠多久呢？

針對上面的情形，讀者應(yīng)該自行評估自己的項(xiàng)目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)。然后寫數(shù)據(jù)的休眠時(shí)間則在讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)基礎(chǔ)上，加幾百ms即可。這么做的目的，就是確保讀請求結(jié)束，寫請求可以刪除讀請求造成的緩存臟數(shù)據(jù)。

如果你用了mysql的讀寫分離架構(gòu)怎么辦？

ok，在這種情況下，造成數(shù)據(jù)不一致的原因如下，還是兩個(gè)請求，一個(gè)請求A進(jìn)行更新操作，另一個(gè)請求B進(jìn)行查詢操作。

1. 請求A進(jìn)行寫操作，刪除緩存
2. 請求A將數(shù)據(jù)寫入數(shù)據(jù)庫了，
3. 請求B查詢緩存發(fā)現(xiàn)，緩存沒有值
4. 請求B去從庫查詢，這時(shí)，還沒有完成主從同步，因此查詢到的是舊值
5. 請求B將舊值寫入緩存
6. 數(shù)據(jù)庫完成主從同步，從庫變?yōu)樾轮?/li>

上述情形，就是數(shù)據(jù)不一致的原因。還是使用雙刪延時(shí)策略。只是，睡眠時(shí)間修改為在主從同步的延時(shí)時(shí)間基礎(chǔ)上，加幾百ms。

采用這種同步淘汰策略，吞吐量降低怎么辦？

ok，那就將第二次刪除作為異步的。自己起一個(gè)線程，異步刪除。這樣，寫的請求就不用沉睡一段時(shí)間后了，再返回。這么做，加大吞吐量。

第二次刪除,如果刪除失敗怎么辦？

這是個(gè)非常好的問題，因?yàn)榈诙蝿h除失敗，就會出現(xiàn)如下情形。還是有兩個(gè)請求，一個(gè)請求A進(jìn)行更新操作，另一個(gè)請求B進(jìn)行查詢操作，為了方便，假設(shè)是單庫：

1. 請求A進(jìn)行寫操作，刪除緩存
2. 請求B查詢發(fā)現(xiàn)緩存不存在
3. 請求B去數(shù)據(jù)庫查詢得到舊值
4. 請求B將舊值寫入緩存
5. 請求A將新值寫入數(shù)據(jù)庫
6. 請求A試圖去刪除請求B寫入對緩存值，結(jié)果失敗了。

ok,這也就是說。如果第二次刪除緩存失敗，會再次出現(xiàn)緩存和數(shù)據(jù)庫不一致的問題。

如何解決呢？

具體解決方案，且看博主對第(3)種更新策略的解析。

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

首先，先說一下。老外提出了一個(gè)緩存更新套路，名為《Cache-Aside pattern》。其中就指出

1. 失效：應(yīng)用程序先從cache取數(shù)據(jù)，沒有得到，則從數(shù)據(jù)庫中取數(shù)據(jù)，成功后，放到緩存中。
2. ***：應(yīng)用程序從cache中取數(shù)據(jù)，取到后返回。
3. 更新：先把數(shù)據(jù)存到數(shù)據(jù)庫中，成功后，再讓緩存失效。

另外，知名社交網(wǎng)站facebook也在論文《Scaling Memcache at Facebook》中提出，他們用的也是先更新數(shù)據(jù)庫，再刪緩存的策略。

這種情況不存在并發(fā)問題么？

不是的。假設(shè)這會有兩個(gè)請求，一個(gè)請求A做查詢操作，一個(gè)請求B做更新操作，那么會有如下情形產(chǎn)生

1. 緩存剛好失效
2. 請求A查詢數(shù)據(jù)庫，得一個(gè)舊值
3. 請求B將新值寫入數(shù)據(jù)庫
4. 請求B刪除緩存
5. 請求A將查到的舊值寫入緩存

ok，如果發(fā)生上述情況，確實(shí)是會發(fā)生臟數(shù)據(jù)。

然而，發(fā)生這種情況的概率又有多少呢？

發(fā)生上述情況有一個(gè)先天性條件，就是步驟（3）的寫數(shù)據(jù)庫操作比步驟（2）的讀數(shù)據(jù)庫操作耗時(shí)更短，才有可能使得步驟（4）先于步驟（5）。可是，大家想想，數(shù)據(jù)庫的讀操作的速度遠(yuǎn)快于寫操作的（不然做讀寫分離干嘛，做讀寫分離的意義就是因?yàn)樽x操作比較快，耗資源少），因此步驟（3）耗時(shí)比步驟（2）更短，這一情形很難出現(xiàn)。

假設(shè)，有人非要抬杠，有強(qiáng)迫癥，一定要解決怎么辦？

如何解決上述并發(fā)問題？

首先，給緩存設(shè)有效時(shí)間是一種方案。其次，采用策略（2）里給出的異步延時(shí)刪除策略，保證讀請求完成以后，再進(jìn)行刪除操作。

還有其他造成不一致的原因么？

有的，這也是緩存更新策略（2）和緩存更新策略（3）都存在的一個(gè)問題，如果刪緩存失敗了怎么辦，那不是會有不一致的情況出現(xiàn)么。比如一個(gè)寫數(shù)據(jù)請求，然后寫入數(shù)據(jù)庫了，刪緩存失敗了，這會就出現(xiàn)不一致的情況了。這也是緩存更新策略（2）里留下的***一個(gè)疑問。

如何解決？

提供一個(gè)保障的重試機(jī)制即可，這里給出兩套方案。

方案一：

如下圖所示

流程如下所示

1. 更新數(shù)據(jù)庫數(shù)據(jù)；
2. 緩存因?yàn)榉N種問題刪除失敗
3. 將需要?jiǎng)h除的key發(fā)送至消息隊(duì)列
4. 自己消費(fèi)消息，獲得需要?jiǎng)h除的key
5. 繼續(xù)重試刪除操作，直到成功

然而，該方案有一個(gè)缺點(diǎn)，對業(yè)務(wù)線代碼造成大量的侵入。于是有了方案二，在方案二中，啟動一個(gè)訂閱程序去訂閱數(shù)據(jù)庫的binlog，獲得需要操作的數(shù)據(jù)。在應(yīng)用程序中，另起一段程序，獲得這個(gè)訂閱程序傳來的信息，進(jìn)行刪除緩存操作。

方案二：

流程如下圖所示：

1. 更新數(shù)據(jù)庫數(shù)據(jù)
2. 數(shù)據(jù)庫會將操作信息寫入binlog日志當(dāng)中
3. 訂閱程序提取出所需要的數(shù)據(jù)以及key
4. 另起一段非業(yè)務(wù)代碼，獲得該信息
5. 嘗試刪除緩存操作，發(fā)現(xiàn)刪除失敗
6. 將這些信息發(fā)送至消息隊(duì)列
7. 重新從消息隊(duì)列中獲得該數(shù)據(jù)，重試操作。

備注說明：上述的訂閱binlog程序在mysql中有現(xiàn)成的中間件叫canal，可以完成訂閱binlog日志的功能。至于oracle中，博主目前不知道有沒有現(xiàn)成中間件可以使用。另外，重試機(jī)制，博主是采用的是消息隊(duì)列的方式。如果對一致性要求不是很高，直接在程序中另起一個(gè)線程，每隔一段時(shí)間去重試即可，這些大家可以靈活自由發(fā)揮，只是提供一個(gè)思路。

總結(jié)

本文其實(shí)是對目前互聯(lián)網(wǎng)中已有的一致性方案，進(jìn)行了一個(gè)總結(jié)。對于先刪緩存，再更新數(shù)據(jù)庫的更新策略，還有方案提出維護(hù)一個(gè)內(nèi)存隊(duì)列的方式，博主看了一下，覺得實(shí)現(xiàn)異常復(fù)雜，沒有必要，因此沒有必要在文中給出。***，希望大家有所收獲。