文章目錄
更多Redis相關問題查看博文:
Redis面試常見問題大綜合
首先，緩存由於其高併發和高性能的特性，已經在項目中被廣泛使用。在讀取緩存方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作。
但是在更新緩存方面，對於更新完數據庫，是更新緩存呢，還是刪除緩存。又或者是先刪除緩存，再更新數據庫，其實大家存在很大的爭議。
首先談談一般不會用到的更新完數據庫再更新緩存
1、更新完數據庫再更新緩存（不推薦）
這麼做引發的問題有兩個
1、如果A,B兩個線程同時做數據更新，A先更新了數據庫，B後更新數據庫，則此時數據庫裏存的是B的數據。而更新緩存的時候，是B先更新了緩存，而A後更新了緩存，則緩存裏是A的數據。這樣緩存和數據庫的數據也不一致。
2、很多時候，在複雜點的緩存場景，緩存不單單是數據庫中直接取出來的值。
比如可能更新了某個表的一個字段，然後其對應的緩存，是需要查詢另外兩個表的數據並進行運算，才能計算出緩存最新的值的。
另外更新緩存的代價有時候是很高的。是不是說，每次修改數據庫的時候，都一定要將其對應的緩存更新一份？也許有的場景是這樣，但是對於比較複雜的緩存數據計算的場景，就不是這樣了。如果你頻繁修改一個緩存涉及的多個表，緩存也頻繁更新。但是問題在於，這個緩存到底會不會被頻繁訪問到？
舉個栗子，一個緩存涉及的表的字段，在 1 分鐘內就修改了 20 次，或者是 100 次，那麼緩存更新 20 次、100 次；但是這個緩存在 1 分鐘內只被讀取了 1 次，有大量的冷數據。實際上，如果你只是刪除緩存的話，那麼在 1 分鐘內，這個緩存不過就重新計算一次而已，開銷大幅度降低。用到緩存纔去算緩存。
其實刪除緩存，而不是更新緩存，就是一個 lazy 計算的思想，不要每次都重新做複雜的計算，不管它會不會用到，而是讓它到需要被使用的時候再重新計算。像 mybatis，hibernate，都有懶加載思想。查詢一個部門，部門帶了一個員工的 list，沒有必要說每次查詢部門，都把裏面的 1000 個員工的數據也同時查出來啊。80% 的情況，查這個部門，就只是要訪問這個部門的信息就可以了。先查部門，同時要訪問裏面的員工，那麼這個時候只有在你要訪問裏面的員工的時候，纔會去數據庫裏面查詢 1000 個員工。
2、先刪除緩存再更新數據庫
1、併發操作問題
該方案會導致不一致的原因是。同時有一個請求A進行更新操作，另一個請求B進行查詢操作。那麼會出現如下情形:
（1）請求A進行寫操作，刪除緩存
（2）請求B查詢發現緩存不存在
（3）請求B去數據庫查詢得到舊值
（4）請求B將舊值寫入緩存
（5）請求A將新值寫入數據庫
上述情況就會導致不一致的情形出現。而且，如果不採用給緩存設置過期時間策略，該數據永遠都是髒數據。
2、還有一個問題就是第一步刪除緩存成功，第二步寫數據庫失敗
造成cache中無數據，db中是舊數據，此時有請求過來，則會查詢舊數據並寫入緩存
那麼，如何解決呢？採用延時雙刪+設置超時時間
僞代碼如下
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秒怎麼確定的，具體該休眠多久呢？
針對上面的情形，讀者應該自行評估自己的項目的讀數據業務邏輯的耗時。然後寫數據的休眠時間則在讀數據業務邏輯的耗時基礎上，加幾百ms即可。這麼做的目的，就是確保讀請求結束，寫請求可以刪除讀請求造成的緩存髒數據。
如果你用了mysql的讀寫分離架構怎麼辦？
ok，在這種情況下，造成數據不一致的原因如下，還是兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作。
（1）請求A進行寫操作，刪除緩存
（2）請求A將數據寫入數據庫了，
（3）請求B查詢緩存發現，緩存沒有值
（4）請求B去從庫查詢，這時，還沒有完成主從同步，因此查詢到的是舊值
（5）請求B將舊值寫入緩存
（6）數據庫完成主從同步，從庫變爲新值
上述情形，就是數據不一致的原因。還是使用雙刪延時策略。只是，睡眠時間修改爲在主從同步的延時時間基礎上，加幾百ms。
採用這種同步淘汰策略，吞吐量降低怎麼辦？
ok，那就將第二次刪除作爲異步的。自己起一個線程，異步刪除。這樣，寫的請求就不用沉睡一段時間後了，再返回。這麼做，加大吞吐量。
第二次刪除,如果刪除失敗怎麼辦？
這是個非常好的問題，因爲第二次刪除失敗，就會出現如下情形。還是有兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作，爲了方便，假設是單庫：
（1）請求A進行寫操作，刪除緩存
（2）請求B查詢發現緩存不存在
（3）請求B去數據庫查詢得到舊值
（4）請求B將舊值寫入緩存
（5）請求A將新值寫入數據庫
（6）請求A試圖去刪除請求B寫入對緩存值，結果失敗了。
ok,這也就是說。如果第二次刪除緩存失敗，會再次出現緩存和數據庫不一致的問題。如何解決呢？
其實就是要提供一個保證能成功刪除的重試機制！！！先看看第3種方案
3、更新完數據庫再刪除緩存(推薦)
首先，先說一下。老外提出了一個緩存更新套路，名爲《Cache-Aside pattern》。其中就指出
- 失效：應用程序先從cache取數據，沒有得到，則從數據庫中取數據，成功後，放到緩存中。
- 命中：應用程序從cache中取數據，取到後返回。
- 更新：先把數據存到數據庫中，成功後，再讓緩存失效。
- 另外，知名社交網站facebook也在論文《Scaling Memcache at Facebook》中提出，他們用的也是先更新數據庫，再刪緩存的策略。
這種情況不存在併發問題麼？
不是的。假設這會有兩個請求，一個請求A做查詢操作，一個請求B做更新操作，那麼會有如下情形產生
（1）緩存剛好失效
（2）請求A查詢數據庫，得一箇舊值
（3）請求B將新值寫入數據庫
（4）請求B刪除緩存
（5）請求A將查到的舊值寫入緩存
ok，如果發生上述情況，確實是會發生髒數據。
然而，發生這種情況的概率又有多少呢？
發生上述情況有一個先天性條件，就是步驟（3）的寫數據庫操作比步驟（2）的讀數據庫操作耗時更短，纔有可能使得步驟（4）先於步驟（5）。可是，大家想想，數據庫的讀操作的速度遠快於寫操作的（不然做讀寫分離幹嘛，做讀寫分離的意義就是因爲讀操作比較快，耗資源少），因此步驟（3）耗時比步驟（2）更短，這一情形很難出現。
假設，有人非要擡槓，有強迫症，一定要解決怎麼辦？
如何解決上述併發問題？
首先，給緩存設有效時間是一種方案。其次，採用策略（2）裏給出的異步延時刪除策略，保證讀請求完成以後，再進行刪除操作。
還有其他造成不一致的原因麼？
有的，這也是緩存更新策略（2）和緩存更新策略（3）都存在的一個問題，如果刪緩存失敗了怎麼辦，那不是會有不一致的情況出現麼。比如一個寫數據請求，然後寫入數據庫了，刪緩存失敗了，這會就出現不一致的情況了。這也是緩存更新策略（2）裏留下的最後一個疑問。
如何解決？
提供一個保障的重試機制即可!!!，這裏給出兩套方案。
方案一：
如下圖所示
流程如下所示
（1）更新數據庫數據；
（2）緩存因爲種種問題刪除失敗
（3）將需要刪除的key發送至消息隊列
（4）自己消費消息，獲得需要刪除的key
（5）繼續重試刪除操作，直到成功
然而，該方案有一個缺點，對業務線代碼造成大量的侵入。於是有了方案二，在方案二中，啓動一個訂閱程序去訂閱數據庫的binlog，獲得需要操作的數據。在應用程序中，另起一段程序，獲得這個訂閱程序傳來的信息，進行刪除緩存操作。
方案二：
流程如下圖所示：
（1）更新數據庫數據
（2）數據庫會將操作信息寫入binlog日誌當中
（3）訂閱程序提取出所需要的數據以及key
（4）另起一段非業務代碼，獲得該信息
（5）嘗試刪除緩存操作，發現刪除失敗
（6）將這些信息發送至消息隊列
（7）重新從消息隊列中獲得該數據，重試操作。
備註說明： 上述的訂閱binlog程序在mysql中有現成的中間件叫canal，可以完成訂閱binlog日誌的功能。 至於oracle中，博主目前不知道有沒有現成中間件可以使用。另外，重試機制，博主是採用的是消息隊列的方式。 如果對一致性要求不是很高，直接在程序中另起一個線程，每隔一段時間去重試即可，這些大家可以靈活自由發揮，只是提供一個思路。
總結：
雙刪延時+設置超時時間
在寫庫前後都進行redis.del(key)操作，並且設定合理的超時時間。這樣最差的情況是在超時時間內存在不一致，當然這種情況極其少見，可能的原因就是服務宕機。此種情況可以滿足絕大多數需求。 當然這種策略要考慮redis和數據庫主從同步的耗時，所以在第二次刪除前最好休眠一定時間，比如500毫秒，這樣毫無疑問又增加了寫請求的耗時
異步淘汰緩存
通過讀取binlog的方式，採用mq異步淘汰緩存，提供一個保障的重試機制!!!
好處： 業務代碼侵入性低，將緩存與數據庫不一致的時間儘可能縮小。
參考文章：
https://blog.csdn.net/qq_16803227/article/details/92001895
https://www.cnblogs.com/senlinyang/p/8830611.html
https://my.oschina.net/u/3691499/blog/3027645
其他文章：
https://my.oschina.net/jiagouzhan/blog/2990423
https://juejin.im/post/5d1aceba5188255d47515002
https://blog.csdn.net/qq_27384769/article/details/79499373