更新緩存

更新緩存的時候涉及兩個問題：

• 刪除（del）還是 修改（set）？
• 先操作數據庫，還是 先操作緩存？

組合起來就有四種情況：

第一種情況：先刪除緩存，后更新數據庫

如果刪除緩存失敗，則后面的操作都不會執行，沒問題；

如果刪除緩存成功，更新數據庫失敗，則緩存與數據庫不一致，但這種不一致會馬上被修正，因而不影響，因為下一次請求緩存的時候發現緩存中沒有，會從數據庫重新加載；但是，又有一個問題出現了，在舊的緩存被刪除后，新的緩存未寫入之前，這段時間內如果有讀操作，那么舊的值會被重新加載到緩存，這就相當於沒更新緩存；

第二種情況：先更新緩存，后更新數據庫

同樣，如果更新緩存成功，更新數據庫是吧，則出現緩存與數據庫不一致，數據不一致就是問題

第三種情況：先更新數據庫，后刪除緩存

如果更新數據庫成功，刪除緩存失敗，則出現緩存與數據庫不一致，數據不一致就是問題

第四種情況：先更新數據庫，后更新緩存

跟第三種情況一樣

 

雖然，看上去好像都有問題，但是，任何脫離實際業務的設計都是耍流氓

既然我們把Redis當緩存，那么所有數據都要以數據庫為准，像上面第二種情況（緩存中有的數據在數據庫中沒有）是不能容忍的，而對於第一種情況，可以采取雙刪的策略（刪除緩存 --> 更新數據庫 --> 再刪除緩存），后面兩種情況，可以用定時任務進行補償，有些場景下我們是可以接受不一致的情況的。

不過，話又說回來，直接刪除緩存當然是最簡單的，它相當於延遲加載（第一次使用的時候發現沒有才會去從數據庫加載），這樣可能導致第一次請求會比較慢；而采用修改緩存的方式，相當於預先加載。

在實際使用的時候，可以采用這兩種方式：

1. 先刪除緩存，再更新數據庫，最后再刪一次
2. 先更新數據庫，然后向MQ發一條消息，由專門的緩存服務去更新數據

 

上面說的是只有一個數據庫實例的情況，而實際生產過程中肯定是一主多從的

按照寫主讀從，緩存加載數據的時候應該從從庫中讀，而本來主從同步就有延遲，於是讀從庫很有可能讀到的是舊數據

為了解決這種問題，可以考慮以下幾種方案：

第一種：強制緩存讀主數據庫

這樣一來，就不必考慮主從同步的問題了，可行（PS：跟微信公眾號開發的時候獲取Token一樣）

第二種：選擇性地讀主數據庫

之所以強制讀主庫，是因為再主從同步完成之前從庫中的數據還是舊的，當主從同步完成后再讀從庫就沒什么問題了，那么如果在主從同步的這段時間內如果沒有請求讀這個KEY就沒有問題，如果這段時間內有請求讀取這個KEY，那么在同步完成后要刪除這個KEY

如何判斷在主從同步這段時間內有沒有請求讀取這個KEY呢？

在更新數據庫的時候，往緩存中設置一個KEY，格式是：緩存KEY+業務數據ID，其生存時間是主從延時時間

比如，假設主從同步延時是3秒，而有業務緩存KEY是hash類型的，更新的這條數據的ID是213，那么在更新數據庫后要立即設置  set USER_213_KV  1  3

在讀的時候，首先判斷緩存中有沒有這樣一個KEY，如果有則從主庫中重新加載數據到緩存，沒有，則直接從從庫中加載數據到緩存

第三種：訂閱從庫的binlog

可以通過工具（比如，canal）訂閱從庫的binlog，這是比較准確的，從庫數據有更新，則立即更新緩存

https://github.com/alibaba/canal

 

補充1：緩存穿透

緩存穿透

緩存穿透，指的是查詢一個數據庫中不存在的數據。這樣的話，每次都會查詢數據庫，相當於緩存就沒有用了。

針對這種情況，可以緩存空值，並設置一個較短的生存時間，比如60秒。

 

緩存雪崩

緩存雪崩，指的是大量緩存在一段時間內集體失效。這樣的話，短時間內大量請求會直接打到數據庫。

針對這種情況，可以在緩存的生存時間后面再加上一個隨機數，這樣的話就不至於同一時刻集體過期。實際上，因為大量緩存失效意味着這些緩存在同一時刻被設置的，而這種情況不多見。

 

緩存擊穿

緩存擊穿，指的是單個緩存在被高並發訪問時失效了導致請求全部打到數據庫。

針對這種情況，在加載緩存的時候要加分布式鎖。

 

補充2：Redis客戶端工具Medis

https://github.com/luin/medis

git clone https://github.com/luin/medis.git
cd medis
npm install
npm run build
npm start