這裡為什麼不讓更新操作在寫完資料庫之後，緊接著去把快取cache中的資料也修改了呢？
主要是因為這樣做的話，就有2個寫操作的事件了，擔心在併發的情況下會導致髒資料，舉個例子：
那麼 cache aside 模式就沒有髒資料問題了嗎？不是的，在極端情況下也可能會產生髒資料，比如：
不過這種概率比上面一種概率要小很多。所以整體而言 cache aside 模式 還是一種比較簡單實用的方式。
這個模式其實就是將 快取服務 作為主要的儲存，應用的所有讀寫請求都是直接與快取服務打交道，而不管最後端的資料庫了，資料庫的資料由快取服務來維護和更新。不過快取中資料變更的時候是同步去更新資料庫的，在應用的眼中只有快取服務。
流程就相當簡單了：
這個模式出現髒資料的概率就比較低，但是就強依賴快取了，對快取服務的穩定性有較大要求，另外，增加新快取節點時還會有初始狀態空資料問題。
這個模式就是 read/write through 模式 的乙個變種。區別就是 read/write through 模式的快取寫資料庫的時候是同步的，而 write behind 模式 的快取運算元據庫是非同步的。
流程如下：
這個模式的特點就是速度很快，效率會非常高，但是資料的一致性比較差，還可能會有資料的丟失情況，實現邏輯也較為複雜。
快取更新策略
一般來說，快取有以下三種模式 cache aside更新模式 這種策略下，在併發寫的時候可能會出現髒資料的問題。read write through 更新模式 在read write through 更新模式中，應用程式只需要維護快取，資料庫的維護工作由快取 了。read through 模式就是在...
Mysql 之 快取更新策略
業務角度，對於讀操作很少的，造成效能浪費 執行緒安全角度，容易產生資料髒讀 執行緒a更新了資料庫，執行緒b更新了資料庫，b更新了快取，a更新了快取 錯誤情況 請求a進行寫操作，刪除快取 請求b查詢發現快取不存在，讀取資料庫，寫入快取 請求a將資料寫入資料庫 解決方法 採用延時雙刪除法 在a寫入資料庫...
Redis快取設計和更新策略
快取背景 對於大面積的qps請求 傳統的資料庫的讀寫分離已經無法滿足。當資料庫的最大連線數 都達到峰值，這時候如果只是一味的加資料的db機器 也許可以緩解一下db壓力。但是資料庫機器一般都比較貴，從經濟成本上來說，不可取。那麼對於像秒殺這種場景，一段時間的查詢量非常大，活動一結束查詢量就會降下來，該...