更新緩存

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

• 刪除（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