redis更新快取的的Design Pattern有四種：Cache aside, Read through, Write through, Write behind caching，我們下面一一來看這四種Pattern。
Cache Aside Pattern
這是最常用最常用的pattern了。其具體邏輯如下： （建議學習：Redis視訊教學）
失效：應用程式先從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相關技術文章，請造訪Redis入門教程欄位進行學習！
以上是redis如何更新快取的詳細內容。更多資訊請關注PHP中文網其他相關文章！
