redis更新緩存有幾種模式

redis更新緩存有幾種模式？針對這個問題，今天小編總結了這篇文章，希望能幫助更多想解決這個問題的朋友找到更加簡單易行的辦法。

redis更新緩存的Design Pattern有四種：Cache aside, Read through, Write through, Write behind caching。

Cache Aside Pattern

這是最常用最常用的pattern了。其具體邏輯如下：

失效：應用程序先從cache取數據，沒有得到，則從數據庫中取數據，成功后，放到緩存中。

命中：應用程序從cache中取數據，取到后返回。

更新：先把數據存到數據庫中，成功后，再讓緩存失效。

注意，我們的更新是先更新數據庫，成功后，讓緩存失效。那么，這種方式是否可以沒有文章前面提到過的那個問題呢？我們可以腦補一下。

一個是查詢操作，一個是更新操作的并發，首先，沒有了刪除cache數據的操作了，而是先更新了數據庫中的數據，此時，緩存依然有效，所以，并發的查詢操作拿的是沒有更新的數據。

但是，更新操作馬上讓緩存的失效了，后續的查詢操作再把數據從數據庫中拉出來。而不會像文章開頭的那個邏輯產生的問題，后續的查詢操作一直都在取老的數據。

Read Through

Read Through 套路就是在查詢操作中更新緩存，也就是說，當緩存失效的時候（過期或LRU換出），Cache Aside是由調用方負責把數據加載入緩存，而Read Through則用緩存服務自己來加載，從而對應用方是透明的。

Write Through

Write Through 套路和Read Through相仿，不過是在更新數據時發生。當有數據更新的時候，如果沒有命中緩存，直接更新數據庫，然后返回。如果命中了緩存，則更新緩存，然后再由Cache自己更新數據庫（這是一個同步操作）

下圖自來Wikipedia的Cache詞條。其中的Memory你可以理解為就是我們例子里的數據庫。

Write Behind Caching Pattern

Write Behind 又叫 Write Back。一些了解Linux操作系統內核的同學對write back應該非常熟悉，這不就是Linux文件系統的Page Cache的算法嗎？是的，你看基礎這玩意全都是相通的。所以，基礎很重要，我已經不是一次說過基礎很重要這事了。

Write Back套路，一句說就是，在更新數據的時候，只更新緩存，不更新數據庫，而我們的緩存會異步地批量更新數據庫。

這個設計的好處就是讓數據的I/O操作飛快無比（因為直接操作內存嘛 ），因為異步，write backg還可以合并對同一個數據的多次操作，所以性能的提高是相當可觀的。

但是，其帶來的問題是，數據不是強一致性的，而且可能會丟失（我們知道Unix/Linux非正常關機會導致數據丟失，就是因為這個事）。

在軟件設計上，我們基本上不可能做出一個沒有缺陷的設計，就像算法設計中的時間換空間，空間換時間一個道理，有時候，強一致性和高性能，高可用和高性性是有沖突的。軟件設計從來都是取舍Trade-Off。

另外，Write Back實現邏輯比較復雜，因為他需要track有哪數據是被更新了的，需要刷到持久層上。操作系統的write back會在僅當這個cache需要失效的時候，才會被真正持久起來，比如，內存不夠了，或是進程退出了等情況，這又叫lazy write。

在wikipedia上有一張write back的流程圖，基本邏輯如下：

關于redis更新緩存的模式就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。