引言

為什么寫這篇文章？

首先，緩存由于其高并發(fā)和高性能的特性，已經在項目中被廣泛使用。在讀取緩存方面，大家沒啥疑問，都是按照下圖的流程來進行業(yè)務操作。

image

但是在更新緩存方面，對于更新完數據庫，是更新緩存呢，還是刪除緩存。又或者是先刪除緩存，再更新數據庫，其實大家存在很大的爭議。目前沒有一篇全面的博客，對這幾種方案進行解析。于是博主戰(zhàn)戰(zhàn)兢兢，頂著被大家噴的風險，寫了這篇文章。

文章結構

本文由以下三個部分組成 1、講解緩存更新策略 2、對每種策略進行缺點分析 3、針對缺點給出改進方案

正文

先做一個說明，從理論上來說，給緩存設置過期時間，是保證最終一致性的解決方案。這種方案下，我們可以對存入緩存的數據設置過期時間，即使本次寫入緩存的數據是臟數據，只要到達過期時間，則后面的讀請求自然會從數據庫中讀取新值然后回填緩存。因此，接下來討論的思路不依賴于給緩存設置過期時間這個方案。 在這里，我們討論三種更新策略：

• 1. 先更新數據庫，更新緩存
• 2. 先刪除緩存，再更新數據庫
• 3. 先更新數據庫，再刪除緩存

為什么沒有先更新緩存，再更新數據庫這種策略？因為如果更新緩存成功，但是數據庫更新失敗，將會導致數據不一致了。

那么第二種方案為什么可以呢？比如刪除緩存成功，但更新數據失敗了，此時并不會造成數據的不一致，因為只是單純的刪除了緩存而已，下次獲取數據時重寫寫入緩存即可。

(1)先更新數據庫，再更新緩存

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

原因一（線程安全角度） 同時有請求A和請求B進行更新操作，那么會出現

• （1）線程A更新了數據庫
• （2）線程B更新了數據庫
• （3）線程B更新了緩存
• （4）線程A更新了緩存

需要注意的是：對于第1步和第2步來說不能并發(fā)的，因為更新數據庫會排他鎖，所以第2步肯定是在第一步完成的情況下執(zhí)行的。

這就出現請求A更新緩存應該比請求B更新緩存早才對，B卻比A更早更新了緩存。這就導致了臟數據，因此不考慮。

正常情況下更新緩存肯定比寫入數據庫速度快，如果出現上面這種場景，表明2，3速度大于4。出現這種情況，只有一種原因就是線程A更新緩存時由于網絡原因阻塞，導致線程B先執(zhí)行完，出現這種情況的概率還是很小的。

原因二（業(yè)務場景角度） 有如下兩點：

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

解決方案

原因一說的線程安全問題，是由于數據沒有加鎖導致的，所以我們可以將“先更新數據庫后再更新緩存”操作寫入到事務內，這樣在更新數據時就會對數據加排他鎖，只有本事務結束后才可以釋放鎖，加事務后肯定會降低系統(tǒng)的吞吐量。

接下來討論的就是爭議最大的，先刪緩存，再更新數據庫。還是先更新數據庫，再刪緩存的問題。

(2)先刪緩存，再更新數據庫

該方案會導致不一致的原因是。同時有一個請求A進行更新操作，另一個請求B進行查詢操作。那么會出現如下情形:

• （1）請求A進行寫操作，刪除緩存
• （2）請求B查詢發(fā)現緩存不存在
• （3）請求B去數據庫查詢得到舊值
• （4）請求B將舊值寫入緩存
• （5）請求A將新值寫入數據庫 上述情況就會導致不一致的情形出現。而且，如果不采用給緩存設置過期時間策略，該數據永遠都是臟數據。

正常情況下，寫數據庫時間肯定大于讀數據庫時間，2和4步操作是緩存中操作速度很快，第3步又是讀庫，所以2，3，4操作比第5步操作快的場景是很容易發(fā)生的，也就是上面描述的這種場景是很容易發(fā)生的。

那么，如何解決呢？采用延時雙刪策略 偽代碼如下

public void write(String key,Object data){
        redis.delKey(key);
        db.updateData(data);
        Thread.sleep(1000);
        redis.delKey(key);
    }

轉化為中文描述就是

• （1）先淘汰緩存
• （2）再修改數據庫（這兩步和原來一樣）
• （3）休眠1秒，再次淘汰緩存 這么做，可以將1秒內所造成的緩存臟數據再次刪除。

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

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

如果你用了mysql的讀寫分離架構怎么辦？

ok，在這種情況下，同樣會造成數據不一致的情況，造成數據不一致的原因如下，還是兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作。

• （1）請求A進行寫操作，刪除緩存
• （2）請求A將數據寫入數據庫了，
• （3）請求B查詢緩存發(fā)現，緩存沒有值
• （4）請求B去從庫查詢，這時，還沒有完成主從同步，因此查詢到的是舊值
• （5）請求B將舊值寫入緩存
• （6）數據庫完成主從同步，從庫變?yōu)樾轮?上述情形，就是數據不一致的原因。

解決方案還是使用延時雙刪策略。只是，睡眠時間修改為在主從同步的延時時間基礎上，加幾百ms。

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

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

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

這是個非常好的問題，如果第二次刪除緩存失敗，將會出現緩存和數據庫不一致的問題，臟數據將會一直存在。 如何解決呢？
可以將第二次刪除操作放到隊列中，有倆個原因，第一隊列可以滿足異步的要求，其次隊列有重試機制，可以保證最終刪除成功。

(3)先更新數據庫，再刪緩存

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

1. 失效：應用程序先從cache取數據，沒有得到，則從數據庫中取數據，成功后，放到緩存中。
2. 命中：應用程序從cache中取數據，取到后返回。
3. 更新：先把數據存到數據庫中，成功后，再讓緩存失效。

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

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

不是的?？隙ㄒ彩菚械牟l(fā)問題的，有以下倆種情況

1. 數據庫為讀寫分離架構
在這種情況下，同樣會造成數據不一致的情況，造成數據不一致的原因如下，還是兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作。

（1）請求A進行寫操作，更新數據
（2）請求A刪除緩存
（3）請求B查詢緩存發(fā)現，緩存沒有值
（4）請求B去從庫查詢，這時，還沒有完成主從同步，因此查詢到的是舊值
（5）請求B將舊值寫入緩存
（6）數據庫完成主從同步，從庫變?yōu)樾轮?上述情形，就是數據不一致的原因。

解決方法：和上述的方法一樣，采用異步延遲雙寫策略,在A請求刪除完緩存之后，在短暫延遲之后在進行一次清楚緩存。

2. 極端情況
假設這會有兩個請求，一個請求A做查詢操作，一個請求B做更新操作，那么會有如下情形產生

（1）緩存剛好失效

（2）請求A查詢數據庫，得一個舊值

（3）請求B將新值寫入數據庫

（4）請求B刪除緩存

（5）請求A將查到的舊值寫入緩存 ok，如果發(fā)生上述情況，確實是會發(fā)生臟數據。

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

發(fā)生上述情況有一個先天性條件，就是步驟（3）的寫數據庫操作和步驟（4）刪除緩存操作執(zhí)行速度要大于第（5）步的寫緩存操作。

我們知道寫數據庫的操作耗時肯定大于讀數據庫的操作，更何況第（5）步是在緩存中操作，那么出現這種極端情況只有一種可能請求A在寫入緩存時由于網絡問題遇到阻塞，導致3，4步率先執(zhí)行。

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

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

延時刪除失敗怎么辦

緩存更新策略（2）和緩存更新策略（3）都存在的延遲刪除失敗的這個問題，上面已經介紹過了，使用一個異步隊列即可，下面詳細介紹

如何解決？ 提供一個保障的重試機制即可，這里給出兩套方案。

方案一： 如下圖所示

image

流程如下所示

• （1）更新數據庫數據；
• （2）緩存因為種種問題刪除失敗
• （3）將需要刪除的key發(fā)送至消息隊列
• （4）自己消費消息，獲得需要刪除的key
• （5）繼續(xù)重試刪除操作，直到成功 然而，該方案有一個缺點，對業(yè)務線代碼造成大量的侵入。于是有了方案二，在方案二中，啟動一個訂閱程序去訂閱數據庫的binlog，獲得需要操作的數據。在應用程序中，另起一段程序，獲得這個訂閱程序傳來的信息，進行刪除緩存操作。 方案二：

image

流程如下圖所示：

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

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

總結

針對第一種方案更新數據庫后在更新緩存和第三方案更新數據庫后在刪除緩存進行比較，到底該使用哪種方案呢？：
這個問題的本質就是更新的數據是不是會被頻繁訪問到，是不是熱點數據了。
如果數據是熱點數據，且使用的是第三種方案更新數據庫后在刪除緩存，這樣將會造成查詢數據時由于沒有查詢到緩存而全部命中數據庫，導致redis緩存雪崩，所以如果是熱點數據，需要使用的是第一種方案更新數據后更新緩存，這種方案可以適合并發(fā)大的場景。
如果數據不是熱點數據，我們則可以使用第三方案更新數據庫后在刪除緩存,這種方案可以避免多次寫入緩存浪費性能。
如果你是一個寫數據庫場景比較多，而讀數據場景比較少的業(yè)務需求，采用這種方案更新數據后更新緩存就會導致數據壓根還沒讀到，緩存就被頻繁的更新，浪費性能。

第一種方案更新數據庫后在更新緩存適合讀多寫少的場景。
第三方案更新數據庫后在刪除緩存適合讀少寫多場景。

給緩存加過期時間是解決數據一致性的最簡單方法，該方法保證最終數據一致性。這種方法的關鍵是怎么設置過期時間，時間設置過長臟數據則會保留時間過長，時間設置過短則會造成頻繁寫入緩存，浪費性能。

參考：
https://zhuanlan.zhihu.com/p/59167071，本篇文章是根據這篇文章總結修改出來的。