一般來說，快取有以下三種模式：
cache aside更新模式
這種策略下，在併發寫的時候可能會出現髒資料的問題。
read/write through 更新模式
在read/write through 更新模式中，應用程式只需要維護快取，資料庫的維護工作由快取**了。
read through 模式就是在查詢操作中更新快取，也就是說，當快取失效的時候，cache aside 模式是由呼叫方負責把資料加載入快取，而 read through 則用快取服務自己來載入。
write through
write through 模式和 read through 相仿，不過是在更新資料時發生。當有資料更新的時候，如果沒有命中快取，直接更新資料庫，然後返回。如果命中了快取，則更新快取，然後由快取自己更新資料庫（這是乙個同步操作）。
write behind caching 更新模式
write behind caching 更新模式就是在更新資料的時候，只更新快取，不更新資料庫，而我們的快取會非同步地批量更新資料庫。這個設計的好處就是直接操作記憶體速度快。因為非同步，write behind caching 更新模式還可以合併對同乙個資料的多次操作到資料庫，所以效能的提高是相當可觀的。
但其帶來的問題是，資料不是強一致性的，而且可能會丟失。另外，write behind caching 更新模式實現邏輯比較複雜，因為它需要確認有哪些資料是被更新了的，哪些資料需要刷到持久層上。只有在快取需要失效的時候，才會把它真正持久起來。
總結
三種快取模式的優缺點：
快取是通過犧牲強一致性來提高效能的。所以使用快取提公升效能，就是會有資料更新的延遲。這需要我們在設計時結合業務仔細思考是否適合用快取。然後快取一定要設定過期時間，這個時間太短太長都不好，太短的話請求可能會比較多的落到資料庫上，這也意味著失去了快取的優勢。太長的話快取中的髒資料會使系統長時間處於乙個延遲的狀態，而且系統中長時間沒有人訪問的資料一直存在記憶體中不過期，浪費記憶體。
快取更新策略初探
這裡為什麼不讓更新操作在寫完資料庫之後，緊接著去把快取cache中的資料也修改了呢？主要是因為這樣做的話，就有2個寫操作的事件了，擔心在併發的情況下會導致髒資料，舉個例子 那麼 cache aside 模式就沒有髒資料問題了嗎？不是的，在極端情況下也可能會產生髒資料，比如 不過這種概率比上面一種概率...
Mysql 之 快取更新策略
業務角度，對於讀操作很少的，造成效能浪費 執行緒安全角度，容易產生資料髒讀 執行緒a更新了資料庫，執行緒b更新了資料庫，b更新了快取，a更新了快取 錯誤情況 請求a進行寫操作，刪除快取 請求b查詢發現快取不存在，讀取資料庫，寫入快取 請求a將資料寫入資料庫 解決方法 採用延時雙刪除法 在a寫入資料庫...
Redis快取設計和更新策略
快取背景 對於大面積的qps請求 傳統的資料庫的讀寫分離已經無法滿足。當資料庫的最大連線數 都達到峰值，這時候如果只是一味的加資料的db機器 也許可以緩解一下db壓力。但是資料庫機器一般都比較貴，從經濟成本上來說，不可取。那麼對於像秒殺這種場景，一段時間的查詢量非常大，活動一結束查詢量就會降下來，該...