比較常用的緩存策略，同樣這也是facebook的緩存策略：?
1. 讀：應(yīng)用程序從cache中取數(shù)據(jù)，取到后返回。?
2. 讀：應(yīng)用程序先從cache取數(shù)據(jù)，沒有得到，則從數(shù)據(jù)庫(kù)中取數(shù)據(jù)，成功后，放到緩存中。?
3. 增刪改：先把數(shù)據(jù)存到數(shù)據(jù)庫(kù)中，成功后，再讓緩存失效。

這里針對(duì)第3點(diǎn)，會(huì)有一些其他的用法，乍一看都是很正常的，但后來細(xì)細(xì)一想其實(shí)都是有問題的。?
比如（1）“先更新redis，然后更新DB”?
（2）“先更新DB，然后更新緩存”?
（3）“先刪除緩存，然后再更新數(shù)據(jù)庫(kù)”

讓我們來看一看這三個(gè)都有什么問題，先假設(shè)更新DB和更新redis都是在同一個(gè)事務(wù)中，其中一個(gè)失敗了就都不操作，或者假設(shè)這兩個(gè)動(dòng)作都不會(huì)失敗。

先看第（1）個(gè)和第（2）個(gè)，Quora上的這個(gè)問答已經(jīng)說明了原因：https://www.quora.com/Why-does-Facebook-use-delete-to-remove-the-key-value-pair-in-Memcached-instead-of-updating-the-Memcached-during-write-request-to-the-backend。

為了更生動(dòng)形象說明問題，我畫了張圖來證明它的不可行性：

從圖中可以看出，兩個(gè)并發(fā)寫操作，由于某些原因（io阻塞，cpu時(shí)間片分配，協(xié)程調(diào)度，網(wǎng)絡(luò)原因等等），導(dǎo)致goroutine2的更新DB晚于goroutine1的更新DB，但是redis中此時(shí)的數(shù)據(jù)goroutine1的，而DB中的數(shù)據(jù)時(shí)goroutine2的，這就出現(xiàn)了不一致的問題，DB中是臟數(shù)據(jù)。

第（2）個(gè)是同樣的道理，見下圖：

下面我們來看第（3），兩個(gè)并發(fā)操作，一個(gè)是更新操作，另一個(gè)是查詢操作，更新操作刪除緩存后，查詢操作沒有命中緩存，會(huì)把老數(shù)據(jù)讀出來后放到緩存中，然后更新操作更新了DB。于是，在緩存中的數(shù)據(jù)還是老的數(shù)據(jù)，導(dǎo)致緩存中的數(shù)據(jù)是臟的，而且還一直這樣臟下去了。
---------------------?
作者：jeffrey11223?
來源：CSDN?
原文：https://blog.csdn.net/jeffrey11223/article/details/78823047?
版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請(qǐng)附上博文鏈接！

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的redis缓存策略小结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。