業務角度，對於讀操作很少的，造成效能浪費；
執行緒安全角度，容易產生資料髒讀(執行緒a更新了資料庫，執行緒b更新了資料庫，b更新了快取，a更新了快取)；
錯誤情況：
請求a進行寫操作，刪除快取
請求b查詢發現快取不存在，讀取資料庫，寫入快取
請求a將資料寫入資料庫
解決方法：
採用延時雙刪除法(在a寫入資料庫後，等待一段時間，再刪除一次快取)
等待時間設定：如果讀寫同步，那麼時間為讀資料業務邏輯的耗時+幾百毫秒；如果讀寫分離，主從同步的延時+幾百毫秒
吞吐量降低解決方法：
第二次刪除用非同步刪除法，開乙個執行緒，非同步刪除。
第二次刪除失敗：
嘗試重新刪除，具體使用訊息佇列
錯誤情況：
快取失效，請求a查詢資料庫
請求b寫入資料庫，請求b刪除快取
請求a將查到的值寫入快取
只有當讀操作比寫操作慢時，請求a才會最後寫入快取
解決併發：
非同步延時刪除策略
刪除失敗導致不一致:
重試機制：使用訊息佇列，巢狀到業務**中(不好)；使用訂閱程式去訂閱資料庫的binlog，另起乙個程式處理快取刪除。mysql訂閱程式外掛程式：canal
快取更新策略
一般來說，快取有以下三種模式 cache aside更新模式 這種策略下，在併發寫的時候可能會出現髒資料的問題。read write through 更新模式 在read write through 更新模式中，應用程式只需要維護快取，資料庫的維護工作由快取 了。read through 模式就是在...
快取更新策略初探
這裡為什麼不讓更新操作在寫完資料庫之後，緊接著去把快取cache中的資料也修改了呢？主要是因為這樣做的話，就有2個寫操作的事件了，擔心在併發的情況下會導致髒資料，舉個例子 那麼 cache aside 模式就沒有髒資料問題了嗎？不是的，在極端情況下也可能會產生髒資料，比如 不過這種概率比上面一種概率...
Redis快取設計和更新策略
快取背景 對於大面積的qps請求 傳統的資料庫的讀寫分離已經無法滿足。當資料庫的最大連線數 都達到峰值，這時候如果只是一味的加資料的db機器 也許可以緩解一下db壓力。但是資料庫機器一般都比較貴，從經濟成本上來說，不可取。那麼對於像秒殺這種場景，一段時間的查詢量非常大，活動一結束查詢量就會降下來，該...